Healthcare
A clinic group cut referral-to-appointment from 11 days to 4
4 days median referral to first appointment, down from eleven, over two quarters
FinanceMVP Development6 min read
Twelve weeks from kickoff to a paid pilot, for a lender whose first customer was a bank security questionnaire
A Series A equipment lender had a signed pilot conditional on passing a bank partner's security review, seven months of runway, and a quote from someone else that ran eighteen weeks and did not mention SOC 2 anywhere.
At a glance
- Client
- a Series A equipment lender in Toronto, roughly 20 people, in Canada
- Industry
- Finance
- Engagement
- MVP Development — fixed scope
- Duration
- 2 weeks discovery, 12 weeks build
- Team
- 3 engineers, 1 architect, fractional delivery lead
- Built with
- React, Next.js, Node.js, PostgreSQL, AWS
What changed
1471137122
weeks from kickoff to the first paying pilot customer
14711
pass on the bank partner's security questionnaire — three clarifications, no remediation project
4704426011
of 96 backlog items deferred in writing before the build started, none of which blocked the pilot
Figures are as reported by the client over the period named in the body below, and were not independently audited by us.
Working on something like this?
Get an estimateThe short version
- The constraint was not the feature list. It was a control that had to be designed in and could not be retrofitted in the fortnight before a security review.
- Two weeks of paid discovery produced an architecture, a ticket-level backlog, and a fixed number — and deferred 41 of 96 items in writing before anyone wrote code.
- Access control, audit logging, and encryption with client-held keys went in during weeks one to three, not weeks ten to twelve.
- The repository was in their GitHub organisation from the first commit and the infrastructure was in their AWS account throughout.
The problem
Underwriting ran on a spreadsheet and a shared mailbox. That is not unusual at Series A and it was not, by itself, the thing that needed fixing — the business was writing deals and the spreadsheet was keeping up.
What needed fixing was a sequencing problem. They had a signed pilot with a bank partner, and the pilot was conditional on passing that partner's security review. The review would ask where customer data lived, who could reach it, and what record existed of who had looked at what. None of those questions have a good answer that can be produced in the fortnight before the review.
- Seven months of runway, against a competing quote of eighteen weeks that made no mention of SOC 2 at all.
- A feature list written for the funding round, not for the pilot — a broker portal, a second product type, and eleven reports.
- No engineering staff. The two founders could specify the product but neither could review an architecture, so anything unmaintainable would stay unmaintainable.
What made it hard
What we did
1
Two weeks of paid discovery, ending in artefacts they owned
Not a proposal deck. An architecture diagram, a ticket-level backlog with an estimate per item, a written assumptions list, and a fixed number. Ninety-six items went into that backlog. Forty-one came straight back out, deferred in writing with the reason attached, so the decision could be revisited later rather than re-argued weekly.
2
Controls first, because controls are the thing that cannot be added late
Single sign-on, per-record audit logging, encryption at rest with keys held in their own account, and least-privilege access all landed in weeks one to three. The evidence for each — the configuration, the policy, the screenshot an auditor asks for — was captured as it was built rather than reconstructed afterwards.
3
Two roles, not four
The specification described four user types. Two of them had a single real user each on day one, and both could be served by an admin flag. Building the full permission matrix would have cost about three weeks and would have been rebuilt once real usage arrived, which is the most expensive order to do things in.
4
Reports became a CSV export
Eleven reports were requested. For the first fifty deals, a well-shaped export into the spreadsheet they already knew how to use answered every question the reports would have. Reporting is worth building once you know which numbers people actually look at twice.
5
Their repository, their cloud, from the first commit
We committed to their GitHub organisation and built in their AWS account, under their bank partner's data residency requirement. That is a security answer as much as a commercial one: the review asked who could reach production, and the answer was their staff and a named list of ours, revocable by them.
Why the broker portal was the right thing to cut
It was the largest single item in the backlog and the most confidently specified, which is usually a warning rather than a reassurance. Confidence in a feature nobody has used yet is a description of an assumption, not of a requirement. The pilot involved one bank partner and no brokers, so the portal could not have been validated during the pilot even if it had shipped — it would have been three weeks of work reviewed by nobody.
What changed
1471137122weeks
kickoff to the first paying pilot customer
Firstpass
on the bank partner's security questionnaire
4704426011of1619995166
backlog items deferred before the build started
The twelve weeks are the headline, but the mechanism is the forty-one deferrals. A twelve-week build is not a faster team; it is a smaller build, agreed in advance, with the reasons written down so nobody had to relitigate them in week seven.
The security questionnaire came back with three clarifications and no remediation work. That is the direct consequence of weeks one to three: the controls existed, and so did the evidence that they existed. Retrofitting the same controls after a failed review is the same work plus a rewrite plus a lost quarter.
The SOC 2 Type I observation window opened four months after launch, which was possible because the control set was already running rather than being designed. The window opening is a fact about a date. Certification is issued by auditors, not by us, and nothing here claims it.
The constraints we worked under
What this engagement did not include
- No broker portal, no second product type, and no reporting suite — deferred in writing, and still deferred at the time of writing.
- Credit decisioning stayed manual. A human read every application. Automating it before there was a body of decisions to learn from would have encoded a guess.
- Collections and servicing were out of scope entirely. The pilot ended before the first payment cycle closed.
- We could not measure the counterfactual. Whether the competing eighteen-week quote would have shipped in eighteen weeks is unknowable, and we make no claim about it.
- One thing we would do differently: we scoped the CSV export as a stopgap and it is still in production. A stopgap that works is a stopgap nobody funds replacing, and we should have said so at the time rather than after.
What they own now
- The repository, in their GitHub organisation, with the full commit history from the first commit.
- The AWS account, the infrastructure as code that builds it, and the pipeline that deploys to it.
- A test suite covering the underwriting and application paths, and a runbook for the two failure modes that woke anyone up during the pilot.
- The control evidence pack assembled during weeks one to three, which is what the SOC 2 observation window ran against.
- The deferred-items list, with the reason each was deferred, so the next decision starts from a record rather than a memory.
When this would not have worked
A twelve-week fixed-scope build is a good fit for a narrow, well-understood problem with a hard external date. It is a bad fit in several situations we would name before quoting.
- If the product question is still open — if you are trying to discover what to build rather than build a thing you have already sold — a fixed scope prices the wrong risk. Scoping an MVP is the piece to read first.
- If nobody on your side can make a decision inside a day, the schedule absorbs the delay and the fixed price stops being fair to either party.
- If the regulatory position is genuinely unknown rather than merely unstarted. Designing against a control set requires knowing which one.
- If the integrations are undocumented and there is no sandbox. Two weeks of discovery cannot de-risk what cannot be called.
If this sounds like your situation
The engagement shape is described on the MVP development page, and the control work is cybersecurity services for finance. If the question you actually have is what it costs, what an MVP costs gives ranges with the assumptions attached, and the SOC 2 readiness timeline covers the sequencing this project turned on.
The features you defer in writing are cheaper than the features you defer by running out of weeks.
“The part we did not expect was how much got cut. We went in with a feature list and came out with a shorter one and a date we actually hit.”
Recognise any of this?
Tell us what is not working. You will get a scoped estimate and an architecture you own, not a capability deck.
Common questions
An MVP can be built with the SOC 2 control set running from the start, which is what happened here — access control, audit logging, encryption with client-held keys, and change management, all designed in during the first three weeks. That is different from being certified. Certification requires an observation window and an auditor, and in this case the Type I window opened four months after launch. Anyone offering you certification in twelve weeks is describing something else.
Because the date belonged to somebody else. When the deadline is a bank partner's quarterly review window, the risk worth pricing is schedule risk, and fixed scope puts that risk on us. It only works because two weeks of paid discovery produced a ticket-level backlog first — a fixed price quoted from a paragraph is a guess with a decimal point on it. Where the trade-off sits in general is covered in fixed price versus time and materials.
They stay on a written list with the reason each was deferred and what would have to be true to pick it up. At the time of writing, most remain deferred, which is the outcome we would expect — a deferral that gets revisited and confirmed is information about the roadmap, and several of those items turned out to describe a market the business decided not to enter.
They did, throughout. We committed to their GitHub organisation and built in their AWS account from the first day, not at handover. This is standard on every engagement, and in a regulated context it is also the simplest answer to the access-control questions a security review will ask.
A twelve-week MVP with a designed-in control set sits in the range described in what custom software actually costs, toward the upper half of the MVP band because the compliance work is real engineering rather than paperwork. The honest answer for any specific project comes out of discovery, not out of a rate card.