Technical Product Partner for Early-Stage Founders
A fixed-scope method for testing one risky product assumption before deciding to build, iterate, or stop.
Abstract
Early-stage founders often face a product decision before they have enough evidence to make it. I work on one defined question at a time. We identify the assumption most likely to reverse the decision, inspect the evidence already available, and design the smallest useful test. The result is a written recommendation to BUILD, ITERATE, or STOP, with the evidence, risks, and limits stated plainly.
Keywords: product decisions; technical feasibility; AI systems; early-stage founders; evidence
- Audience
- Early-stage founders
- Outcome
- BUILD, ITERATE, or STOP
- First format
- 75 minutes
- Beta fee
- USD 120
Problem statement
A polished prototype can prove that an interface can be assembled. It does not prove that a user will change behavior, that the required data exists, that a vendor permits the integration, or that the delivery cost works.
The expensive mistake is not slow coding. It is committing time and money before naming the assumption that could invalidate the product.
Proposed intervention
The work starts with a decision, not a feature list. Existing evidence is separated from opinions. Architecture, permissions, cost, and operating constraints enter the test only when they can change that decision.
The smallest useful proof may be a technical spike, a manual workflow, a narrow prototype, an evidence review, or a cost model. It is not a complete MVP.
- Product question
- Existing evidence
- Riskiest assumption
- Smallest useful test
- Observed evidence
Engagement formats
The Product Decision Session fee is credited toward an accepted Idea-to-Proof Sprint.
| Format | Use it when | Included | Timing | Beta fee |
|---|---|---|---|---|
| Product Decision Session | You have a concrete decision but do not know what evidence would resolve it. | About 10 minutes of pre-work, a 75-minute session, and a one-page Founder Decision Brief within 24 hours. | 75 minutes | USD 120 for the first five clients. Later USD 180. |
| Idea-to-Proof Sprint | A small functional proof or technical spike is needed before the decision can be made. | Two sessions, one risky hypothesis, a fixed-scope proof, limited feedback, risks, and a 30-day plan. | 7 days | USD 550 for the first three cases. Later USD 850. |
Outputs
Every engagement ends with a decision and its reasoning. The exact artifacts depend on the question.
- One-page Founder Decision Brief
- Evidence and assumption map
- Technical spike or narrow functional proof
- Architecture and cost note
- Risks and explicit decision rule
- Prioritized 30-day plan
Selected technical evidence
These are public artifacts, not client results. They show implemented work and documented reasoning. They do not show adoption, scale, or commercial outcomes.
Public system
Study
The public repository and interface show a document-to-notes-and-flashcards workflow. Using Summary or Flashcards requires a visitor-supplied Google Gemini API key. These artifacts do not establish demand or business performance.
Prototype
Gemini file-search prototype
The inspected repository code implements client-side interactions for file-search store and import, uploaded-document context, image attachments, streamed responses, and source metadata. The linked note documents architecture and cost reasoning. This is not evidence of a deployed app or production system.
Selected writing
SRE infrastructure and edge-platform notes
Two public technical notes name VPS and SRE infrastructure topics and AI and edge-platform tradeoffs. They show documented reasoning only, not implementation, measurement, client work, or external validation.
Scope and limitations
- One engagement addresses one primary product question.
- The work does not guarantee product-market fit, funding, revenue, technical success, or any commercial result.
- It does not replace user research when user evidence is required.
- A complete MVP, open-ended implementation, and indefinite support are outside scope.
- I accept one active sprint at a time.
- I do not accept logistics, last-mile, delivery management, route optimization, fleet, dispatch, delivery tracking, or adjacent competitive work.
Application and procedure
There is no public calendar and no public checkout. An application starts a fit and conflict review.
- 01Application
- 02Fit and conflict review
- 03Acceptance
- 04Payment
- 05Private booking
- 06Pre-work
- 07Session
- 08Founder Decision Brief
- 09Optional sprint
Submitting an application does not create a client relationship, reserve a meeting, or collect payment.
Author note
Pablo Cardozo is an AI engineer and Technical Product Partner based in Buenos Aires. His public work includes AI product interfaces, retrieval prototypes, and documented infrastructure analysis.
Do you have a product question worth testing?
Describe the observed problem, the evidence you have, and the decision you need to make.
Submit a product question →