The Six Weeks Before We Write Any Code (And Why It Cuts Custom Software Budgets in Half)

Most clients we talk to about a custom software build come in expecting the same shape of project. A short discovery call, a couple of weeks of wireframes, and then development starts. The contract is signed, the deposit is paid, and code starts appearing.

That is not how we run a build. And the reason is not philosophical. It is financial. The clients who let us spend roughly six weeks on the pre-code phase consistently end up with cheaper, more flexible software that survives the changes their business is going to throw at it. The ones who insist on skipping the pre-code phase consistently pay for it later, in rewrites, in stalled features, and in the kind of bills that come with the phrase "this is going to be a bigger job than we thought."

Here is what those six weeks actually look like, with three real examples from recent projects in three different industries.

Step one: clickable prototypes, not wireframes

The first thing we build is not a sketch and not a low fidelity grey box mockup. We build a clickable, fully designed prototype in Figma. The buttons go to the right places. The empty states are there. The error messages are written. The dashboards have realistic data in them.

The reason is simple. A wireframe asks the client to imagine the app. A clickable prototype lets the client use it. Those are different cognitive tasks, and they surface different problems. We have had clients approve wireframes and then completely change direction the moment they clicked through the prototype, because the experience of moving from screen to screen revealed something the static drawings did not.

On a recent realtor facing app project, the first round of prototype review came back with 34 comments in a single batch. Every one of those comments was a discovery that would have cost real money to find in code. Some were UX preferences. Some were business logic gaps. One was a missing edge case that would have broken the messaging feature on launch day. All of them were fixable in Figma in an afternoon.

Step two: the API decisions get made on paper

This is the step most agencies do not do at all, and it is the single most expensive omission in custom software.

Every app that talks to outside data sources is built on hinges. An app for real estate professionals depends on a real estate data feed. A livestock diagnostics app depends on a way to capture and verify test results. A legal records platform depends on an authentication and document storage layer. Each one of those hinges has multiple options, and each option commits the app to a different future.

On the realtor app we mentioned above, the API decision was a real choice between three serious options for property data: a paid aggregator, a board level data feed agreement, and the public consumer facing service. Each had different coverage, different costs, different licensing rules, and different feature ceilings. The aggregator was faster to integrate but added a recurring expense and limited the app's listing freshness. The board feed was the cleanest data but required individual agreements with regional boards. The consumer service was free but came with hard caps on what the app could legally display.

We made that decision in Figma. Specifically, we designed three slightly different versions of the listing search screen and the property detail screen, one for each data source, with notes on what each would and would not show. The client saw the tradeoffs visually before any developer wrote a single integration. The chosen path locked in cleanly. Nobody had to rewrite a data model.

The same logic applies in every industry. We have made these decisions in advance for veterinary and livestock tech projects (where a diagnostic workflow has to fit how a vet actually moves through a barn, not how a software developer imagines it), and for legal industry tools (where document retention rules, e-signature legality, and provincial privacy law change what the data model is even allowed to do). In every case, the cost of getting it wrong is paid in the code, weeks or months later. The cost of getting it right is paid in design, in hours.

Step three: a design system that survives a rebrand

Here is a story that proves the point harder than any sales pitch.

One of our recent app projects was a diagnostic tool for the livestock health industry. Partway through the build, the entire brand changed. New name, new logo, new colour palette, new tone. The kind of change that on a poorly structured project would mean throwing out months of work and starting over.

The total cost to absorb the rebrand was roughly one billable week. No screens were thrown out. No flows were restructured. The app survived the rebrand because the design system underneath it did not have brand colours and brand names hard coded into every screen. Buttons referenced a token called "primary action," not a hex value. Headings referenced a typography token, not a specific font. The product name appeared in exactly one variable, not 200 places.

That is what a design system actually does, and it is built in the pre-code phase. If you do not have one when you start coding, you do not get to add one later without rebuilding most of the app.

Step four: scope gets sharp, not vague

The other thing that happens in the six weeks before code is the scope document gets specific. Not "users can manage their listings" but "users can change a listing's status between four defined states, and changing status to sold triggers a notification to the listing agent and any agent with a saved search matching the property."

That second version of the scope can be built. It can be quoted accurately. The developer knows when they are done. The client knows what they are paying for. The first version is a recipe for an open ended timeline and a relationship that ends badly.

We have built this kind of detailed scope for projects across veterinary diagnostics, real estate, legal records management, and agricultural manufacturing. In every case, the scope document that comes out of the pre-code phase is two or three times the size of what came in. That growth is not bloat. It is the difference between an idea and a buildable specification.

The math on why this works

Pre-code changes are nearly free. Post-code changes are not. Some concrete numbers from recent work:

Changing a button colour in a Figma file: minutes.

Changing a button colour in a shipped app where the colour is referenced 200 times in the code: hours to a full day, plus testing, plus a release cycle.

Adjusting a user flow in Figma: a few hours of design work.

Adjusting the same user flow after code is written: typically three to five times the original development cost for that section, because the surrounding pieces have to be rewritten too.

Swapping a data integration in Figma: a refactored data model and a new design pass on a few screens.

Swapping a data integration in production: weeks of work, potential downtime, migration of any data that has already accumulated, and sometimes a forced redesign of features that depended on the old integration's quirks.

Across the projects we have run in the last twelve months, the clients who fully invested in the pre-code phase spent significantly less per delivered feature than the industry average. The clients who insisted on shortcutting it paid more, took longer, and ended up with apps that fought back when they tried to evolve them.

What you should expect from any custom software agency

Whether you hire us or somebody else, here is what to ask for in the pre-code phase:

A clickable prototype, not a wireframe. If you cannot navigate it on your phone or in a browser, it is not a real prototype.

A written rationale for major technical decisions, especially API and integration choices. If you do not understand why a particular data source or auth provider was chosen, you are not ready to build.

A design system, not just a logo and some screens. There should be tokens for colour, typography, spacing, and components. Ask to see them.

A detailed scope document, not a one page summary. If your scope can be written on a single page, your project has not been thought through.

A phased build option. Most custom software does not need to be delivered all at once. A good agency will tell you what the smallest valuable first phase is, and what can wait.

What this means for your project

The pre-code phase is what changes the budget math on a custom software build. Not the developer hourly rate. Not the framework. Not the country your developers happen to live in. The decisions made before anyone touches code.

If you are weighing a custom app, a web platform, or a piece of internal software for your business, the question to ask is not "how much will it cost to build" but "how much will it cost to live with for the next five years." The pre-code phase is what determines the answer.

We are happy to talk through what your pre-code phase would look like, what your specific industry's integration landscape involves, and where the cost hinges in your project are. The easiest way to start that conversation is to email us at hello@nerdyspider.com or call the office at 587-417-5870.

If your last software project went over budget, the reason is almost certainly buried in the six weeks before anyone wrote any code. The good news is that the next one does not have to.

‍