How we kick off a product: our MVP development process, from $5,000

Our MVP development process starts with a proposal. It lists the people who would build your product, what each of them will do, the hours we expect the work to take and each person’s rate. Plans start at $5,000. The first block of work stands alone, and at the end of it you hold the architecture, a working foundation and a firm price for the rest of the build. The code is in your repository from the first commit.

9io is a product engineering studio, a small team of senior engineers with a fractional CTO, a designer, a product manager and QA. We have kicked off products in healthcare, ecommerce, edtech and fintech. Every engagement runs on the same terms whatever we’re building, and they’re in the proposal before you sign anything. The sector changes what the first block has to settle, and a companion post covers each of the four.

The sections below follow a build in order, from the proposal to what each sector adds, and end with a checklist for the kickoff.

What the proposal shows before you commit

A first message only needs a few lines about what the product is, where it’s at and what’s missing. The reply comes from the person who would do the work, and it tells you if we’re not the right fit.

If the build goes ahead, you pay for the hours in the proposal, with no management fee and no hidden extras. We don’t publish hourly rates, because the right figure depends on which roles a product needs and for how long. Every rate is in the proposal before you commit, along with the terms on our how we work page. Work usually starts within a couple of days of agreeing a proposal, and if we can’t start that quickly, we say so.

Whichever MVP development company you talk to, ask for the hours behind its price, broken down by person. A fixed price is still an estimate of hours multiplied by a rate, as our cost model for AI apps sets out.

The first block, our version of a discovery phase

In software development, the discovery phase is when a team learns about the users and the problem before committing to build. The UK government’s Service Manual says a team shouldn’t start building during discovery, and treats stopping at the end of it as a legitimate result when the research points that way.¹

Our first block does that job and ends with working code. You come out of it with the architecture, a working foundation in your repository and a firm price for the rest of the product.

The block stands alone. You can carry on with us, take the work to another team or stop, and there’s no retainer to unwind.

How our MVP development process runs after kickoff

After the product kickoff, the work runs in short stages, because the risk in hiring any team is a long silence followed by a big reveal.

The early staging link lets you react to the real product while changes are still cheap. While you review one stage, the team is already on the next, so nothing waits on a reply. If a checkpoint misses its agreed criteria, we fix it at our cost.

Each invoice points at checkpoints you can open, and anything that slips moves to the next invoice. Holding back a tenth of each one keeps acceptance meaningful and the amount at stake small for both sides. Copy changes, design tweaks and SEO adjustments are part of the job, at no extra charge.

The team comes in three sizes, called reduced, full and accelerated. They differ only in how many people are on the work and how fast it moves.

Who owns the code, and how you would leave

Code, history and infrastructure definitions live in your repository from the first commit, so there’s nothing to hand over at the end. Ownership transfers milestone by milestone as you pay. Until it does, you hold a licence that can’t be revoked, so a commercial question never holds up the work.

Delivered work carries a 90-day warranty, and we fix anything defective in that time. The architecture is documented and the runbook kept current, so an in-house team or another studio can take the product over without calling us.

What’s included as standard, and why it belongs at kickoff

Where they apply to what you’re building, these are part of the job by default. The last column says why each belongs at kickoff.

What the first block settles in healthcare, fintech, edtech and ecommerce

In each of these sectors, a few rules decide part of the architecture, so the first block has to settle them before features get built. The table pulls them together as of 23 October 2026.

Healthcare. HIPAA applies to health plans, clearinghouses and healthcare providers that carry out certain billing transactions electronically. A vendor that creates, receives, maintains or transmits protected health information (PHI) for one of them is a business associate, and HHS says that includes a cloud provider holding only encrypted data without the decryption key.² A business associate agreement (BAA) has to be in place before PHI reaches that vendor.³ So the first block should list every service that would see PHI, from hosting and email to error tracking, analytics and model APIs, and get a BAA from each or keep PHI out of it. Health apps outside HIPAA may fall under the FTC’s Health Breach Notification Rule instead.⁴ Our healthcare post covers BAAs with AI vendors in more depth.

Fintech. Start with who holds the licence. In the US, a money services business generally has to register with FinCEN within 180 days of being established,⁵ and states license and supervise money transmitters too.⁶ A company can hold the licences itself or work through a bank or another licensed partner, and that choice decides whose rules the product follows. Design the ledger before the first payment flow, as append-only double-entry records that every balance is calculated from. PCI DSS covers every system that stores, processes or transmits card data or could affect its security,⁷ so where card numbers flow sets how much of the product is in scope. Our fintech post goes through what to settle first.

Edtech. If a product is aimed at children under 13, or you know it collects their personal information, the FTC’s COPPA Rule requires verifiable parental consent before collecting it. The amended rule, with a compliance date of 22 April 2026, adds separate consent for disclosing a child’s data to third parties unless that is integral to the service, plus a written security programme and a written retention policy.⁸ Consent records and deletion dates belong in the first data model. A US Justice Department rule requires state and local governments, including public schools and universities, to make web content and mobile apps meet WCAG 2.1 AA, even when someone else provides them under an arrangement. The deadlines are now 26 April 2027 for governments serving 50,000 people or more and 26 April 2028 for the rest.⁹ Our edtech post comes from our work on an AI study platform.

Ecommerce. For payments, decide early whether the store can qualify for SAQ A, the PCI self-assessment for merchants whose account data functions are completely outsourced to PCI DSS validated and compliant providers. Since January 2025 it has also required merchants to confirm their site isn’t susceptible to attacks from scripts that could affect their e-commerce systems,¹⁰ which shapes both the checkout and how third-party scripts get onto the site. Set the performance budget against Google’s Core Web Vitals. They count a page as good when its largest visible element renders within 2.5 seconds, it responds to input within 200 milliseconds and its layout shift score stays at 0.1 or less, at the 75th percentile of page loads.¹¹ The European Accessibility Act applies to e-commerce services for EU consumers from 28 June 2025, except for microenterprises of fewer than 10 staff with no more than €2 million in turnover or balance sheet.¹² The ecommerce post uses our field notes from a fashion commerce platform.

A software project kickoff checklist

If you’re working out how to start building an app with an outside team, have these ready before the kickoff.

• The goal. What the product has to do for its first users, and how you’ll know it worked.
• The users. Who uses it first, on which devices and in which countries. The countries decide which consent and accessibility rules apply.
• Constraints. A budget range, technology you have to keep, integrations that must work at launch and anything else that can’t change.
• Existing code and accounts. Access to any repository, cloud account, domain, app store listing and payment provider, held in your company’s name. If the code is a prototype from an AI app builder, our checklist for taking a vibe-coded app to production shows what to check first.
• Data. What exists, where it lives, who can see it, and whether any of it is health, payment or children’s data.
• Compliance needs. Which of the rules above apply, what certifications or security questionnaires your customers will ask for, and any agreements you already hold, such as a BAA.
• Who accepts milestones. One person who can review each checkpoint within seven working days and sign off against the agreed criteria.
• Any deadline. A fixed date, such as a launch event or the start of a school term, and why it’s fixed. It affects which of the three sizes fits.

Frequently asked questions