A four-week product decision engagement

Most product failures are not execution failures. They are decision failures.

FPCTO is a four-week engagement that takes you from strategy in your head to a buildable plan, with the decisions that matter surfaced and made deliberately.

Book a discovery call See our past work
The problem

Two patterns explain how consequential decisions get missed. I solve for both of them.

The biggest decisions do not announce themselves.

The most consequential calls do not look like decisions. They look like clean outlines on a whiteboard, and then get expensive once the gaps are filled with development assumptions nobody examined. By the time you notice them, the cost of changing them has multiplied. The work is to surface them before they are built, while they still cost a conversation to change, not a rebuild.

These are not the builder's calls to make.

Dev teams have never been able to read a founder's mind, and AI is even worse at it. The conventional answer is to route the load-bearing technical decisions to the technical person, the builder, the CTO, the agency. But these are product decisions, and product decisions belong to the founder. Surfacing them, with the context to decide deliberately, is how the vision survives contact with the build.

Who this is for

Three buyers, one engagement

01 / Pre-build

Funded founders before a build

You are about to commit to a stack, a team, and a v1 scope. What you set in the next thirty days is not just a v1; it is the product operating system your company will run on, the spine on which every future version is built. Decisions surfaced and made deliberately now compound in your favor.

02 / Post-v1

Founders scaling or migrating a working v1

The v1 worked. Now you are committing to what comes next, scaling it or moving it onto new infrastructure. The decisions that got you here will not be the ones that carry you forward, and the next build will lock in whatever you decide now.

03 / Investor diligence

VCs and angels protecting what they fund

Independent diligence on the product decisions before the build begins. Commissioned before the check clears, required as a term of the investment, or run in the first weeks after close. It prices build risk before the spend goes out, by someone without a stake in the project being greenlit.

Case study  /  Origin story

The engagement that showed me what I do best

I have coached dozens of founders through building their products. When I reflect on my work with Ohana, a pattern emerges that I have been acting on for years without naming. FPCTO is that pattern, made deliberate.

William Halbert, Jacob Halbert, Tonya Aiossa, and Ezra Gershanok at BubbleCon 2024

BubbleCon 2024. Left to right: William Halbert, Jacob Halbert, Tonya Aiossa, Ezra Gershanok.

$60M
Annual Stripe volume,
on track for 2026
$38M+
Earned by hosts
in payouts since 2024
1,200+
Multiproperty hosts
on the platform
3 markets
Expansion underway:
London, Berlin, Australia

The engagement

Jacob Halbert and Ezra Gershanok came to me in November 2022 with no development experience, considering outsourcing the build to an agency. They chose to build Ohana themselves and I became their technical coach. Over roughly two years I delivered 95 hours of one-on-one coaching, 99% of it personally, plus unlimited Office Hours access.

The work was hands-on and technical. Jacob and Ezra made their own strategic calls and brought me the next question: they had decided what to build, and they needed to know how to build it. When they settled on their transaction fee strategy, I helped them structure it flexibly in the data model, then map out which Stripe calls and which workflows would make that model real. The same was true of identity verification and sublease enforcement. They made each product decision, and I made sure the build underneath it was sound, secure, and scalable. Together we co-developed the payments infrastructure, the most complex and most critical part of the product. I also served as a professional reference for their successful Neo Accelerator application.

Part of what I brought was pushback. When Jacob and Ezra made a call, I told them where I thought it would lead, drawing on principles earned over years of seeing how a faithfully built product can still fail the business that asked for it. The decision stayed theirs. My job was to make sure they made it with the technical consequences in plain sight.

To be precise: Jacob and Ezra built Ohana, raised its funding, and grew it. I had no part in the raises or the business strategy. My contribution was technical, making sure the product they had decided to build was built well.

What it taught me

Ohana is the engagement I can point to by name, but the pattern has held across every founder with whom I have worked. The hours that changed the trajectory of a product were never the ones spent fixing a workflow. They were the early ones: choosing what to build and how to structure it, and catching the strategic decisions that look clean on a whiteboard but get expensive once they are technical product. That is the work founders rarely know to request.

Over my career I have watched founders harden strategic decisions into their products and pay for it later, once the true cost surfaces after the build. A two-sided marketplace, as one of many examples, has to decide at signup whether one person can be both buyer and seller. Neither choice is automatically right. Allow both roles in one account and the data model gets harder, because every transaction has to know which party is which. Keep the roles in entirely separate accounts and you protect that simplicity but lose the relational data between a user's two roles, which is exactly the data you need if you want to understand and iterate for your most engaged users.

The right call depends on the app, the business, and knowing the end users and their needs. To get that call right, the trade-offs need to be in plain view of the founder, so the decision is not inadvertently outsourced to the dev team. What I have learned, pattern after pattern, is that a founder's most consequential decisions usually do not announce themselves as decisions at all.

FPCTO is that work, named and made deliberate. It is a focused four-week engagement covering product framing, a decision inventory, data architecture, and the build-level calls a founder does not yet recognize as decisions. Ohana received that thinking spread across two years of coaching. FPCTO is the same thinking, concentrated.

I met Tonya when I was just starting my Ohana journey, and thank God I did. She co-developed our payments infrastructure with us, the most complex and most critical part of our product, and she's been there every time we needed her. Jacob Halbert. Co-founder, Ohana. BubbleCon 2024 Founder of the Year.
Ohana on Stripe: stripe.com/customers/ohanaThe platform: liveohana.ai Download the full case study (PDF) →
How the engagement works

One engagement, three tiers of depth

One engagement, sold at three tiers of increasing depth, delivered personally by me. The work is surfacing the load-bearing technical decisions and the context you need to make them deliberately. You commit at the depth that fits where you are, and the work itself shows you whether to go further.

Tier 01

Founder Decisions

The first two weeks, and a valid place to stop. I produce the Product Frame, which articulates your strategy in technical terms: what the product is and why, who it is for, how it creates and captures value, the trust model, the v1 boundary, the central hypothesis, the strategic tensions worth naming. Then the Decision Inventory catalogs every load-bearing decision the product requires, including the cross-cutting ones you did not recognize as decisions, and records how each was resolved. Alongside both, the Financial Model is a five-year, monthly, driver-based pro forma whose drivers are the product decisions themselves, the financial expression of the Decision Inventory in the language you take to a board and to investors. A founder who stops here leaves with a complete strategic foundation they can hand to any developer, agency, future PM, or future investor.

Tier 02

Blueprinting

The full four weeks. Tier 2 adds the Blueprint: the buildable artifact that converts your decisions into screens, data schema, and builder-ready documentation a human or AI developer executes against. Screen-by-screen scope where the rendered design is the spec, a single canonical data schema with role and conditional permissions, and per-screen build inputs. The Technical Notes ship as code as context: ground truth for an AI developer, not loose guidance. A blueprint a developer can build against without ambiguity, and a founder can read without a translator.

Tier 03

Product Audit Preparation

The full four weeks. Tier 3 adds the Test Specification: instructions that do not just confirm the product does what it should, but actively attempt to break it, find weaknesses, and probe the edges. Code can pass every frontend test while failing at the data layer, and it can pass both frontend and backend tests while still hiding structural problems, whether a human or an AI wrote it. So the specification works in three parts: what to verify in the interface, what to check directly in the database, and a code audit, instructions for examining the code itself for soundness, structure, security, and maintainability. Every part is written for human and AI testers alike. It prepares the founder and team to audit the build rigorously against the spec that defined it.

The cascade

Why the investment keeps paying off

Every durable deliverable stays provisional until the engagement ends. A discovery made later in the work propagates back up into the earlier one it affects, so the Product Frame, the Decision Inventory, and the Blueprint never diverge from each other. The revision rate drops sharply at each step, but nothing is frozen.

This is the spine of the methodology, and it is what makes the artifacts worth keeping. A durable artifact is not a document written early and locked; it is the single canonical place a decision lives, kept current. Maintained that way, your product operating system keeps paying off through every version, not just the first build. The strategy and the build stay in agreement long after the engagement ends.

That is why Blueprinting routes its new load-bearing decisions to you, not the dev team. Many of those decisions are as consequential as the ones addressed in Founder Decisions. I surface each with the context to decide deliberately, resolved across targeted live meetings and async review. Left to the dev team, the strategy and the v1 build diverge; the routing is what keeps them in agreement.

Who is in the room

You make every load-bearing technical decision

The load-bearing technical decisions are yours; the work is to surface them and bring you the context to make each one deliberately. The conventional move is to route these to the technical person, a builder or a CTO. That is the wrong move. These are product decisions, not just engineering decisions, and product decisions belong to the founder.

I do the majority of the authoring, and you come in for the decisions that need you. Every decision in every artifact carries a tag, new, revised, or open, so you can see at a glance what is moving and where the open calls are. The load-bearing ones I flag and present with the context to decide each one deliberately. Catching contradictions and propagating their resolutions across artifacts is my work, too.

A technical advisor working alongside a founder typically settles the load-bearing calls themselves and presents finished work for the founder's approval. The strategic decisions get inadvertently outsourced. My model inverts that: I do the work that does not need you, surface the work that does, and the strategic decisions stay yours.

Blueprinting routes new load-bearing decisions to you, too, not the dev team. I continue to surface them; the cascade keeps everything cohesive and consistent.

We meet for two to three hours a week. Review on your own schedule.

We meet on a regular cadence for targeted live sessions where I bring the load-bearing decisions to you with the context to resolve each one deliberately. Between sessions I keep working; your review is never the bottleneck. At the end of every working session I send a Change Summary: a digest of what is new, what changed, and what is still open since your last review. Change Summaries cumulate. If a previous summary has not been reviewed, the next one rolls it forward in full; nothing falls off the list and you never face a backlog. The async-review surface is built into the engagement, not an add-on.

The full artifact map +
Tier 1  ·  Founder Decisions
•

Product Frame durable layer

Articulates your strategy in technical terms. Drafted first as a provisional hypothesis, closed by a two-sided sign-off when both of us agree it is done, and kept current through the cascade.

•

Decision Inventory durable layer

Catalogs every load-bearing decision the product requires and how each was resolved. Every entry carries a tag, new, revised, or open, so the state of each decision is visible at a glance. A working document across sessions, regenerated at full fidelity between sessions, with a complete version produced after the Inventory completes. This is where the Frame gets pressure-tested hardest; contradictions surfaced here are deliberated properly, and the resulting decisions propagate up into the Frame.

•

Financial Model durable layer

A five-year, monthly, driver-based pro forma whose drivers are the product decisions themselves: the monetization model sets revenue, the trust and verification decisions set costs, the platform decisions set infrastructure. The financial expression of the Decision Inventory, built from your decisions and kept current through the engagement. It is the one artifact whose audience is your board and your investors rather than a builder.

Tier 2  ·  Blueprinting
•

The durable layer

Product-level targets that everything else points up to: the Screen Index (the canonical map of every screen), the Data Schema (one definition of all entities, fields, and relations, each carrying both its technical and UI-facing name), the Design System (palette, typography, components, voice), the Product Documentation for users and your team, the Operations Runbook (how the platform is operated: secret rotation, backups, incident response, and scheduled maintenance), and the hard Out-of-Scope-for-V1 boundary.

•

Per-screen build inputs

Every per-screen artifact is a build input the builder, human or AI, reads. The Screen Render is the rendered production HTML and CSS, where the render is the spec and there are no redlines. User Interactions define what each action does and where it navigates. Screen Notes, Scope Notes, and the Technical Notes (instrumented as code as context) complete the picture.

•

Strategic Options & Product Backlog

What surfaces during scoping but does not belong in the v1 build gets captured rather than lost. Strategic Options is the higher-altitude map of future directions and pivots, the "what's next" a founder reaches for once the product is live. The Product Backlog is the version-tagged list of deferred features.

Tier 3  ·  Product Audit Preparation
•

Test Specification

Instructions in three parts: what to verify in the interface, what to check directly in the database, and a code audit - instructions for examining the code itself for soundness, structure, security, and maintainability. Code can pass every frontend test while failing at the data layer, and pass both frontend and data layer tests while still hiding structural problems, whether a human or an AI wrote it. Every part is written for human and AI testers alike. It prepares the founder and team to audit the build rigorously against the spec that defined it.

Included in every tier
•

Deliverables Review

A closeout where I review the delivered artifacts with you and explain how they relate to the build and to managing the product afterward, scaled to the tier you purchased.

Beyond the engagement, ongoing options exist for clients who want help keeping the product operating system current, training an in-house product manager, or auditing the build (either initially or on a regular cadence). These get discussed on the discovery call when relevant.

Pricing

Three tiers, one engagement

One engagement, three tiers of depth. Tier 1 is the first two weeks and a valid place to stop. Tiers 2 and 3 carry through the full four weeks.

Tier 1 lets you commit at lower cost, see the value of the Frame and Inventory firsthand, and decide from lived experience whether to continue.

Tier 01
$35,000
Founder Decisions
First 2 weeks
  • Product Frame durable layer
  • Decision Inventory durable layer
  • Financial Model durable layer
Tier 02
$55,000
Blueprinting
Full 4 weeks
  • Everything in Founder Decisions
  • Blueprint Durable layer Screen Index, the canonical map of every screen Data Schema, one canonical definition with role and conditional permissions Design System and the Out-of-Scope-for-V1 boundary Product Documentation for users and your team Operations Runbook, how the platform is operated Per screen Screen Render, where the production design is the spec User Interactions, every action and where it navigates Screen Notes, Scope Notes, Technical Notes as code as context Captured along the way Strategic Options and a version-tagged Product Backlog
Tier 03
$70,000
Product Audit Preparation
Full 4 weeks
  • Everything in Blueprinting
  • Test Specification durable layer Frontend, what to verify in the interface Data Layer, what to check directly in the database Code, what to audit for soundness, structure, security, and maintainability
The math that matters

A load-bearing decision surfaced and settled deliberately during the engagement costs a few minutes to a few hours to resolve before anything is built on top of it. The same decision left to surface on its own in the product costs far more, including the work to unwind it, the team's time spent building the wrong thing, and the runway that went to shipping in the wrong direction. One major miss, or a few minor ones, can cost a founder their startup.

Prerequisites build in order: Tier 2 includes Tier 1, and Tier 3 includes both. Tier 3 adds no duration over Tier 2; the added cost reflects my hours inside the same four weeks.

Tonya Aiossa
About

Tonya Aiossa

I am the technical counterpart to a founder's strategic vision. I am not a strategy advisor and not a business coach. My job is to make sure the technical decisions underneath your vision actually serve that vision.

I came up at AirDev as a developer, was promoted to product manager after my first two engagements, and was then brought in to train other PMs in the program that produced the bench. Across my career I have had a hand in more than one hundred production apps, and I have seen, over and over, what happens when a faithfully built product still fails the business that asked for it. That pattern is what FPCTO is built to interrupt.

I also run Pro NoCoders, a software agency now in its fifth year and rebranding to CoCreative Apps. For most of those five years I ran our Office Hours personally: more than 1,500 sessions, with over one hundred founders and developers bringing their products through, and not one session cancelled or postponed.

When I push back on a strategic call, the pushback comes from the build, not the boardroom. I tell founders when a strategic decision carries a technical cost they have not yet priced into the plan. The principles I draw on were earned over years of seeing the difference up close.

Book a discovery call

Thirty minutes to see whether this is the right fit

The call is where we work out whether the engagement fits what you are building, which tier matches the project, and what your first two weeks look like.

Schedule on Google Calendar