Ten weeks to a funding date, and an MVP launched inside it
A startup with a rough prototype and a fixed funding date came to Atyantik. They had ten weeks left to hit an investor milestone. They had zero internal developers. The first production-ready version of their MVP launched in 9.5 weeks, meeting that deadline.
The number is the easy part to repeat. Through the nine weeks of building, the founder always knew exactly where things stood.
There was a demo of working software every week. A scope review ran beside it, every week. Any change was written up with time, effort, and cost laid out before approval.
That is a claim you can test against your own last project. Ask yourself what you knew in week six, and how you came to know it. The ten weeks ran in three phases, and they carry a limit worth stating plainly.
Where they started
The situation they were in
A rough prototype, a date already said out loud in a room that matters, and nobody in-house who could build. Two of those are ordinary software-engineering conditions. The date is the one that changes the shape of the work. It had already been promised to people whose confidence cannot be bought back.
What was actually in hand. This was the starting position, stated plainly. Each line on its own is manageable. The combination is what makes a ten-week window tight.
- A rough prototype that proved the idea and ran nothing a paying customer could rely on.
- Ten weeks left to hit an investor milestone, with the date already committed in front of people.
- Zero internal developers, so there was no team to brief, correct, or hand a specification to.
- No settled answer yet on which parts of the product had to exist by the milestone.
- A product whose scope had never been written down anywhere both sides could point at.
- A founder who would carry any slip personally, in front of people with long memories.
Where the weeks go
The weeks that get eaten before anyone writes code
Scoping is where a fixed window is usually lost. On this Atyantik engagement it took five days.
On a fixed-date build the schedule risk shows up before any code does. Deciding what the first version must do can take weeks on its own. Every week spent settling that question is a week not spent building. The milestone does not move to compensate.
Here it took five days. Together, we rapidly defined the MVP scope and a crystal-clear delivery plan. That is a process which often takes other firms weeks. Scope in days, not weeks, is how we state the intent.
That is a claim about speed and nothing more. It measures how long the deciding took. Whether the resulting plan was right is a separate question. This engagement answers that only by what came after.
What five days bought was ordinary and large. Building started in the first week rather than the third. The nine weeks that followed went into the product itself. None of them went into arguing about what the product was.
How the ten weeks ran
Three phases, in the order they happened. The first phase sits inside the ten weeks, not before them.
- Day 1 to Day 5
Scoping ran first, because everything after it depends on the answer. Together, we rapidly defined the MVP scope and a crystal-clear delivery plan. Five days, start to finish. What came out was a written scope both sides could point at, and a delivery plan the founder could hold.
- Weeks 1 to 9
Our senior team built the backend and frontend in parallel. Weekly demos and scope reviews ran with the client throughout. The demo was of working software, not a status update. They always knew exactly where things stood. Every change request became a change note, with time, effort, and cost laid out before approval.
- Week 10
We launched the first production-ready version in just 9.5 weeks, meeting the deadline. The measured event in Atyantik's engagement record is that launch: 9.5 weeks against a ten-week commitment. Documentation, deployment pipelines, and the operational runbook went across with the code.
The measurement
Ten weeks committed, 9.5 weeks to a production-ready launch
One engagement, one measurement, taken from Atyantik's own engagement record. The bar is the deadline the startup had already committed to in front of investors. The mark inside it is the first production-ready launch. There is no second engagement here, and no category average.
Show data table
| Measure | Value | Target | Range |
|---|---|---|---|
| First production-ready launch | 9.5 weeks | 10 weeks | 0 weeks to 11 weeks |
9.5 weeks against a ten-week deadline. The threshold was set by the startup, before we were involved. One engagement, and the comparison is to the date rather than to any other build. The date held.
The three things that ran the whole way, and what each one produced
01
Weekly demo
Our senior team built the backend and frontend in parallel, and every week they showed the client working software. The demo was the meeting.
What the client held
A running build the founder could open and use, week after week.
02
Scope review
A scope review ran beside every demo. The plan and the build were compared while both were still moving. That is the only point at which comparing them changes anything.
What the client held
A current, agreed view of scope, checked against what existed rather than against what was promised.
03
Every change
Every change request became a change note, with time, effort, and cost laid out before approval. The change only enters the plan once you sign off, confirmed in a meeting and in writing.
What the client held
A written change note, on the record before anyone acts on it. Nothing in the build moves on a re-scope you have not explicitly accepted.
Underneath the demos
How the code was checked while it was being written
The demos showed what existed. These are the checks that ran underneath them, on every change, for the whole build.
- Every change goes through code review by a senior software engineer.
- GitFlow, with unit tests and integration tests running against every branch.
- CI/CD that gates every merge, so nothing reaches the main line unchecked.
- A core team assigned only to the project, with a lead software engineer the client can talk to directly.
- The same people from start to finish, with no handoffs the client did not agree to.
- Every developer proposed has been vetted by our own technical team first.
- Documentation starting on Day 1 and staying current through delivery.
None of these is unusual on its own. Together they are the reason a weekly demo can be believed. A demo of code nobody reviewed shows you something that runs. It tells you very little about what happens next.
These are commitments rather than measurements. They are the sort of thing worth asking any firm to state before work starts.
If it goes wrong, or if you simply want to leave
You stop halfway, and the code and the accounts turn out to sit somewhere you cannot reach.
If you have your own Git hosting, cloud accounts, and storage, we work inside them. If you do not, we provision them, set them up, and hand the keys over. That second branch is the one that applied here, with zero internal developers in the building.
What we commit to
You own it. From Day 1, every line of code is your IP.
You decide to move the work in-house or to another partner.
So far, no client has needed to use it.
What we commit to
The handoff is a process, not a hostage situation. The freedom is yours from Day 1.
You offboard us and discover the knowledge walked out with the people.
Every project starts with documentation: architecture, deployment, CI/CD pipelines, BRD, SRS, and change notes. Those last two are the business requirements and the software requirements, written down.
What we commit to
If you offboard us, you keep everything including the operational runbook.
You want us to stay, and worry that we are built to hand off and go.
Either path is fine; we plan for both at intake.
What we commit to
We engineer for handoff to your in-house team if that is your direction. Or we stay as long as the platform needs us.
What it establishes
What the ten weeks produced, and what they do not prove
The result, stated once, with its limits stated in the same breath.
In Atyantik's own engagement record, the first production-ready version launched in 9.5 weeks, meeting the startup's deadline. In the first month after launch, the client reported that no users had left. We have not published the user count behind that figure. It is their measurement rather than ours.
These three phases are not a standard schedule and they are not a repeatable one. They are what happened on one engagement, with one scope, one starting position, and one date. A different product or a different set of unknowns produces different weeks. We would not put a ten-week figure on your build before seeing what you have.
Nothing here says the launch caused what came next. That is the sequence, and it is all the sequence supports. The next funding round then closed on time.
Through the nine weeks of building, the founder always knew exactly where things stood. Demos every week, a scope review beside each one, and a written change note before anything moved.
A single sign-on migration across five login systems is written up the same way, with its own limits attached. The service this engagement belongs to is MVP development, and that is where its terms are set out.
Questions we get asked about a build on a fixed date
Can you do this in ten weeks for us?
Who owns the code if we stop?
What happens if the timeline moves?
What if we do not have our own repos or cloud accounts?
Whether this shape of engagement is the right call for you
Where we fit
You have a date you have already committed to in front of people who matter.
You have a rough prototype or a clear product idea, and something concrete to build from.
Every person who can settle a scope question is reachable inside a single week.
You want to own the code, the repositories, and the cloud accounts from the first day.
You would rather see working software every week than read a status report about it.
You are prepared to make decisions quickly, because a fixed window spends its slack on waiting.
You want the scope, the plan, and every change written down where both sides can point at it.
Where we are the wrong call
You are still deciding what the product should do, and nobody can settle scope inside one week.
You have no date yet, and you would rather get the shape of the product right first.
You need the scope to keep changing through the build without the date changing with it.
The version to send to whoever else has to agree
Most decisions like this get made by someone who never reads the write-up. This panel is written to stand alone when it is forwarded.
Forward this part
A ten-week MVP build for a startup with a rough prototype and a fixed funding date
- The situation. A startup with a rough prototype and a fixed funding date. Ten weeks from an investor milestone, with zero internal developers.
- The result. In Atyantik's engagement record, the first production-ready version launched in 9.5 weeks, meeting the deadline. The next funding round then closed on time.
- How it stayed visible. Weekly demos of working software, and a scope review beside each demo. Time, effort, and cost laid out before approval.
- Who owns it. Every line of code is the IP of the client from Day 1. Where a client has no Git hosting or cloud accounts, Atyantik provisions them and hands the keys over.
- What a change costs. Every change request becomes a change note, with time, effort, and cost laid out before approval. Nothing in the build moves on a re-scope you have not explicitly accepted.
- What it does not prove. These phases are not a standard schedule and they are not repeatable as one. This was a single engagement with its own scope and its own starting position. The funding round is what happened next, not something the launch caused.
Tell us the date you are working to
Two good outcomes: a scoped conversation, or a clear no.
If you have a date and something to build, the useful next step is scoping.
We will say what a first production-ready version would need to include. We will also say what we would want to see before putting any span on it.
If the answer is that we are the wrong firm for it, you will hear that instead. A clear no in week one is worth more than a hopeful yes in week six.
- Everything you share stays private.
- A senior software engineer reads what you send.
- You get an answer, including when the answer is no.