The first week is for killing bad ideas

We used to open a new engagement the way every agency does. Kickoff deck. Repo. CI. A Figma file that already assumed the product. By Friday you had a board full of tickets and a quiet feeling that nobody had agreed what “done” meant.

The expensive part was not the setup. It was the third month, when a founder asked why the thing on screen could not answer the one question their sales lead actually needed. We had built the wrong spine, neatly.

So we flipped the first week. No production code until we can name the decision the software is supposed to unlock. If we cannot name it, we are decorating a guess.

Three questions before a repo exists

We put these on a single page. If the room cannot answer them in an hour, the project is not late — it is undefined.

1. Who is blocked today, and what do they do instead? Spreadsheet, WhatsApp group, a person named Ankit who “just knows”.
2. What must be true in 90 days that is not true now? A number, a workflow, a customer conversation you cannot have yet.
3. Which technical choice would be painful to reverse after six months? Datastore, tenancy model, identity, the thing that looks boring and is not.

Notice what is missing. Stack. Sprint velocity. “AI strategy”. Those come after. If a vendor leads with the stack, they are selling capacity, not a product.

We have sat in rooms where the stack was decided before the user was named. Next.js versus Rails is a cheap argument. Whether the first slice is a queue for humans or a customer-facing status page is an expensive one. Get those in the wrong order and you will still have a handsome repo.

Kill the gold-plated version early

Every brief we see has a shadow product hiding in it. Real-time everything. A custom admin. A mobile app “while we are at it”. Multi-region on day one because someone read an AWS blog on a Sunday.

We write the gold-plated version down on purpose. Then we cross out anything that does not serve the 90-day test. People relax when they see the idea was heard. They get sharp when they see it will not ship in this slice.

Last August we sat with a team that wanted a “platform”. What they needed was a single intake form, a queue, and a status the customer could see without calling. The platform language was fear of looking small. The queue was the business.

Crossing things out is the part clients remember. Not because we are negative. Because someone finally said the mobile app is a second product, and the second product has its own 90 days. You can want it. You cannot smuggle it inside the first contract as a bullet.

A thin architecture that can survive year two

Killing scope is not the same as being sloppy. The first slice still needs a tenancy story, an audit trail if money or health data is nearby, and a way to extract data when you outgrow the first store. That is different from building the warehouse now.

• Postgres is still the default. We have never regretted starting there. We have regretted starting with a document store because the object “might get messy”.
• Auth is a product decision. If you bolt on a login screen in week five, you will redo roles in week twenty.
• Background jobs get a real queue on day one if anything can take more than two seconds. A cron on the web process will lie to you.
• Observability is three things: a request id, structured logs, and one dashboard the founder can open without us. Not twenty-seven Grafana panels.

The year-two test is simple. Can you add a second tenant without rewriting the schema? Can you move file storage without rewriting the product? Can you change the email provider without a heroic weekend? If the answers are no, you did not make a thin architecture. You made a demo that hardened.

What the week actually looks like

Monday is interviews. Not “stakeholder alignment”. We sit with the person who does the job, watch them share a screen, and write down every time they leave the official tool. Tuesday we draft the one-pager and the non-goals. Wednesday we argue. Thursday we pick the irreversible bet and sketch only that part of the system. Friday we send the page and wait for the sceptical co-founder to reply.

Someone always asks why we are not “ramping the team”. Because five engineers without a killed idea is a more expensive first week, not a faster one. One engineer and one product person who can write will outperform a full squad decorating the wrong spine.

If there is already a codebase, week one still happens. We do not pretend a greenfield ritual applies to a seven-year monolith. We still name the decision, the seam, and the non-goals. Then we open the repo. The order matters. Opening the repo first trains everyone to discuss files instead of outcomes.

Pushback we hear, and what we do with it

“Our investor wants to see progress.” Progress is a forwarded page that says what will not ship. Investors who have been through a rewrite know the difference. The ones who do not will learn when the demo cannot survive a sales call.

“We already know what to build.” Good. Then the page takes forty minutes. We have never regretted writing it. We have regretted skipping it because the room felt aligned. Alignment that is not written down is a mood.

“Just give us a technical proposal.” We will, on Friday, after the product sentence exists. A proposal that starts with Kubernetes is a brochure. You can get those for free.

What we refuse to estimate in week one

Story points. A twelve-month roadmap. A headcount that assumes the gold-plated version. We will give a range for the first slice once the page exists — usually in weeks, with the risks named. We will not give you a Gantt that survives contact with the first real user.

If procurement needs a number to open a PO, we price the discovery week and the first slice as two lines. Mixing them is how a “fixed bid” becomes a hostage situation when the idea was still moving.

The first slice estimate includes the boring work people forget to price: auth, the audit trail, the one dashboard, the staging restore. If a vendor’s quote is half of ours, check whether those lines exist. They will exist later, on your invoice, with interest.

The Friday test

At the end of week one we want a document the client can forward without us on the thread. Problem, non-goals, first slice, risks, and the one architectural bet we are making. If they cannot forward it, we wrote for ourselves.

Code can wait until Monday. A bad idea should not.