Every project we take on at ATIS starts with a discovery phase, followed by a first two weeks of build. By the end of those two weeks, the client already has a working piece of their own project, running in a real environment, that they can open and test for themselves.
The way we run that opening is deliberate. It reflects practices used at some of the most demanding engineering organizations, and it lines up with what a decade of research into software delivery keeps finding. What follows is how it works, and why the start of a project earns this much attention.
Discovery: understanding the project before building it
Discovery usually takes between one and four weeks, depending on how complex the project is and how clearly it’s defined at the start. Its purpose is to understand the project properly before anyone commits to building it, which means working through it together with the client rather than accepting a brief at face value.
Deciding before you build is something the largest engineering organizations have made a formal step. Amazon begins a new product by writing its press release and a list of frequently asked questions before any code exists, working backwards from the customer. Most teams at Google write a design document that is reviewed and argued over before implementation starts, which works as a kind of code review for a decision that hasn’t been built yet. The point in both cases is the same. The cheapest place to find a problem is on paper, while changing your mind still costs nothing.
Much of discovery is about surfacing things the client hasn’t had a reason to think about yet. Requirements rarely arrive complete. A feature that sounds simple on its own often turns out to depend on several others, or to change how an existing part of the business has to work. We spend this phase mapping how the different pieces of business logic relate to one another, because those relationships are where hidden requirements and later surprises tend to live. When one part of a system depends on an assumption about another, that assumption is worth making explicit at the start, not discovering once it’s running.
We also work with the client to pin down the real scope of the most important functionalities. It’s easy to agree that a system needs billing, or reporting, or user management. It’s much harder, and much more useful, to agree on where each of those actually begins and ends. Getting specific about the core features early is what keeps them from growing on their own later and taking the timeline with them.
Two more things get settled here. One is how the system is likely to grow, since it’s far cheaper to leave room for expansion while the shape of things is still being decided than to retrofit it later. The other is external dependencies: the third-party services, APIs, and platforms the project will need to work with, each of which brings its own constraints and its own ways of breaking.
By the end of discovery, the engineering decisions the build depends on are made: the technology stack, the architectural patterns, the infrastructure approach, and the tools the team will use. The client, meanwhile, has a clear and shared picture of what’s being built and why, before any code exists.
The first days: structure and pipelines
With those decisions in place, the two-week build opens with the project’s foundation. Repository, folder structure, coding conventions, dependency management, and the local setup a developer needs to get running in minutes rather than half a day. Then the pipelines: continuous integration wired in from the first commit, so tests run and builds get checked before anything questionable makes its way in.
Setting this up first, instead of bolting it on once problems appear, is one of the better-supported decisions in the field. The DORA research program, now a decade of surveys across tens of thousands of teams and summarized in the book Accelerate, found something that isn’t obvious at first: speed and stability go together. The teams that ship fastest are usually the ones whose changes fail least, and much of what gets them there is automation and integrating small changes continuously rather than in large, risky batches. A pipeline from day one is what makes that possible later.
None of this is glamorous. It’s plumbing. It’s also the point where the project stops being a set of documents and becomes a real place. There’s a repository to open, commits landing, and builds that pass or fail for visible reasons. This early, there’s already something concrete to look at instead of a plan.
Database engineering
Once the skeleton is up, a few days go into the database before any feature code is written.
This is deliberate, and it comes from a plain observation about where change is expensive. Almost everything in a system can be reworked later without too much pain: code refactored, screens redesigned, services swapped out. The database is the exception. Once real data lives in it and application code depends on its shape, correcting a bad design gets costly fast, and it only gets harder as the data grows. The choices made on the first day, how things are keyed, how they relate, how they’ll be queried, are the ones that compound the most over a system’s life.
So we design the schema properly up front, with real thought given to access patterns, indexing, and the migration path a year or two out. There’s a second benefit to this for the client. A data model is often the clearest technical picture of a business, its core entities and the rules that connect them, with everything else stripped away. Reviewing it together is usually the first time a client sees their own business reflected back in the system, and it catches misunderstandings while they still cost nothing to fix.
Real features, running in staging
In the second half of the second week, application code gets written. The aim isn’t a demo that looks good in a screen share. The aim is working functionality that runs through the whole pipeline and lands in a staging environment that behaves the way production will.
There’s a name for this. Alistair Cockburn called it a walking skeleton; The Pragmatic Programmer calls it a tracer bullet. The idea is to build the smallest slice that runs from end to end, touching the interface, the business logic, the database, and any external service, and to get it deployed early through the real build and release process. It isn’t a throwaway prototype. It’s production code doing very little, and that’s exactly what makes it useful: it exercises the riskiest parts of a system, the integrations and the deployment path, while there’s still time and little cost to fix whatever it turns up.
Running it in a production-like staging environment matters for the same reason. Keeping development, staging, and production as close as possible (what the Twelve-Factor App methodology calls dev/prod parity) is what stops a problem from hiding until launch. Bugs that would otherwise surface in production tend to appear earlier, where they’re cheaper to deal with.
By the end of the two weeks, then, there’s something real in staging, running behind a working pipeline, tested rather than described. This is the part that changes how the project feels from the client’s side. Until now they’ve been hearing about progress. Now they can use it. They can open staging themselves, click through what’s been built, try to break it, and ask about the parts that don’t behave the way they expected. A closed ticket tells a client what we say we’ve done. A feature they can log into and use shows them what’s true, and lets them check it for themselves.
Who benefits
Setting up the beginning of a project this carefully pays off in three directions at once.
The project itself is the first. The riskiest questions (whether the architecture holds up, whether the integrations work, whether the thing actually deploys) get answered in the first two weeks rather than the last two, when they’re expensive and there’s no slack left to absorb them. The foundations are deliberate, so whatever gets built on them stays easier to change as requirements move.
