How we run the first two weeks of a project
The first two weeks decide more about a project's outcome than the following six months. Here is what we do in them — and why we don't write code yet.
Clients sometimes expect a software project to start with software. Ours starts with questions. The first two weeks are dedicated to understanding the business well enough to build the right thing — and to agreeing, together, on what "right" means.
Days 1–3: listen and observe
We begin with conversations: with the people who asked for the project, and just as importantly with the people who will use it. Where possible, we watch the work happen — at the desk, on the shop floor, at the reception counter. We collect the documents, spreadsheets and tools currently in use. Nothing is too small: a sticky note on a screen often explains more than a specification.
Days 4–6: map the process and the data
Next, we draw what we learned. A one-page process map shows who does what, where hand-offs happen and where time is lost. In parallel, we look at the existing data: what exists, where it lives, how reliable it is. Many projects change shape at this point, when the real bottleneck turns out to be somewhere other than expected.
Days 7–9: define the first version
With the problem understood, we define a first version: the smallest scope that removes the most important pain. We write it as user flows and business rules, sketch the key screens, and outline the data model. Equally important, we write down what is not in the first version, so expectations stay aligned.
Days 10–12: prototype and validate
We turn the key flows into a clickable prototype and put it in front of real users. Their reactions — where they hesitate, what they expected to find — are the cheapest feedback a project will ever get. We adjust until the flows feel natural.
What we ask from you
Discovery works best as a collaboration, and it asks relatively little of your team — but the right little:
- A decision maker who can clarify priorities and settle trade-offs quickly.
- Two or three people who do the work every day, available for conversations and prototype sessions.
- Access to what exists: documents, spreadsheets, screenshots of current tools and, where appropriate, sample data.
- Honesty about constraints: budget ranges, deadlines, regulations and the internal politics that shape adoption.
In return, you get a clear picture of the problem and a plan you can act on — whether or not the next step is building with us.
Days 13–14: a plan you can decide on
The two weeks end with a clear package: the problem statement, the process map, the validated prototype, the scope of the first release, a technical approach and a realistic plan. At that point, you can make an informed decision about building — with us or not.
We would rather spend two weeks understanding a problem than two months building the wrong solution.
That is the part of the work that rarely appears in a portfolio. It is also the part that makes everything after it faster.
Working on something similar?
We help companies turn problems like this one into working products. Tell us what you’re dealing with.
