Why the first two weeks decide the project
Most software projects are not lost in month four. They are lost in week one, when nobody wrote down what success actually looks like, and everyone left the kickoff call with a slightly different picture in their head.
So we treat the opening fortnight as a deliverable in its own right, not as a warm-up. At the end of day fourteen you hold real artefacts — a repository, a running environment, a clickable prototype and a scope you have signed off. If you walked away at that point, you would still own something useful.
Days 1 to 3 — Discovery, not a questionnaire
Discovery has a bad reputation because it is usually a form you fill in and never see again. Ours produces a document you will actually reference in month three.
The one number we insist on
Before anything else, we agree on the single metric this project has to move. Signups per week. Cost per acquisition. Hours saved in operations. Support tickets deflected.
It has to be one number, it has to be measurable today, and you have to care about it. If we cannot name it, that is a signal the project is not ready — and we would rather say so in week one than in month four.
What we look at that you might not expect
- Your existing analytics, if you have any, to establish an honest baseline
- The three competitors your customers actually compare you against
- How your team works today, including the spreadsheet everyone secretly relies on
- Whatever you have already built, so we extend rather than replace it out of habit
By day three you have a written scope: what is in, what is explicitly out, and what we have parked for a later phase. The out-of-scope list is usually the most valuable page in the document.
Days 4 to 7 — Architecture and a clickable prototype
Why we prototype before we write production code
It is far cheaper to move a button in Figma than to move it after it has an API behind it. By the end of week one you are clicking through the real flows on your own phone — not reviewing static screenshots in a slide deck.
This is where most of the scope arguments happen, and that is exactly where you want them. Changes at this stage cost hours. The same changes in week six cost days.
The technical decisions we lock early
In parallel we settle the choices that are expensive to reverse later: the data model, how authentication works, where it will be hosted, and which third-party services you are committing to. Each one gets a short written rationale.
We deliberately architect for the scale you are heading toward, not the scale you might reach in five years. Over-engineering an MVP is just a slower way of failing.
Days 8 to 14 — The first working slice
A thin slice, not an empty shell
By the second Friday, something real runs on a staging URL you can open. Not a homepage with placeholder text — one complete user journey working end to end, front to back, with real data moving through it.
For a marketplace that might be: sign up, list one item, have it appear in search. Narrow, but genuinely finished. It proves the architecture holds before we build another twenty features on top of it.
Your repository, your accounts, from day one
The code lives in your GitHub organisation from the first commit, not ours. Cloud infrastructure sits in your account. You watch commits land in real time and you can hand the whole thing to another team whenever you like.
If a client cannot leave, the relationship is being held together by lock-in rather than by the quality of the work. We would rather it be the second one.
What you actually hold at day fourteen
- A written scope with an explicit out-of-scope list
- The one metric this project has to move, with today's baseline recorded
- A clickable prototype of every core flow
- A dated delivery plan for the remaining build
- A staging environment running one complete journey
- Full access to the repository, the cloud account and every service we set up
Why we work this way
Because the alternative is asking you to trust a slide deck for six weeks and hope. Two weeks in, you have enough evidence to judge whether we are the right team — while changing your mind is still cheap.
That cuts both ways. It is also when we find out whether the project is as well-defined as everyone assumed. Occasionally the honest answer is that it is not, and both sides are better off knowing early.
If you have something you are trying to get built, tell us what it needs to do and we will scope the first two weeks for you.
Written by · Founder & Software Developer
Ayush Arya
Co-founder of FlikTech. Builds the product side — platform architecture, APIs and the systems our clients' businesses run on. Still writes production code on every engagement.
Want this applied to your business?
Reading about it is step one. Book a free consultation and we'll map it to your actual situation.
Start a conversation →