A Fixology discovery takes 2 to 4 weeks and is led by a senior developer and a designer. You get process maps, a clickable prototype tested with your staff, a written specification, an integration and data plan, an architecture and hosting plan, a risk register and a phased delivery plan. Everything belongs to you, and any competent team can build from it.
What you have in your hands when discovery ends
A discovery is only worth doing if it produces things you can use, whether or not you build with us. At the end of a Fixology discovery you receive:
| Deliverable | What it contains | Who uses it |
|---|---|---|
| Problem statement | One page: what is going wrong today, what it is holding back, and how you will measure success | Directors signing off the project |
| Process maps | How work flows now and how it will flow with the new system, including the exceptions | Operations leads and the build team |
| Users and permissions | Every type of user, what each can see and do | Developers, and your data protection lead |
| Clickable prototype | The key screens in Figma, clicked through with real users | Staff who will use it, and the designers |
| Prioritised backlog | User stories with acceptance criteria, split into must-have and later | Everyone, as the agreed scope of the build |
| Data and integration map | Where data lives now, what moves where, which APIs (Xero, HubSpot, Microsoft 365, etc.) | Developers and your IT provider |
| Architecture and hosting plan | Technology choices with reasons, UK or EU hosting region, security approach | Your technical adviser or CTO |
| Risk register | The unknowns, how likely they are and how the plan handles them | Directors and the delivery lead |
| Phase plan | Release order, a sprint-by-sprint timeline in weeks, and every assumption in writing | Whoever signs off the build |
For a smaller project some of these are a page each. For a system that replaces a core process, the specification can run to 30 or 40 pages. Either way, it is written in plain English, not code.
Who does the work in a Fixology discovery
Discovery is not a sales exercise. At Fixology it is run by a senior developer and a designer, the same kind of people who would build the system, so every decision is made by someone who understands what it means in code. That is the standard we hold ourselves to, and it is the main reason our specifications survive contact with the build.
Over 2 to 4 weeks they do real work: interviews with the people who use the current process, mapping, prototyping, reading API documentation, testing connections to your systems and looking at your actual data. Only a developer can tell you that your stock system's API cannot return the field you need, or that half of last year's job records have no customer attached.
You deal with those people directly, with no account manager relaying questions. When discovery ends, the developer who led it walks you through every document.
How the weeks run
A discovery takes 2 to 4 weeks, depending on how many teams and systems are involved. A typical three-week discovery for a business system looks like this.
Week 1: listen and map
A half-day kick-off with the project sponsor, then short interviews with the people who do the work: the office manager who reconciles the spreadsheet, the engineer who fills in the job sheet, the finance assistant who rekeys invoices into Sage. We map the current process, including the workarounds nobody mentions in the first meeting. We also collect sample data and look at the systems involved.
Week 2: shape the solution
We sketch the new process and build a clickable prototype of the screens that matter most. You and two or three of your staff click through it on a call, and we change it until it matches how the work really happens. In parallel, a developer tests the riskiest technical assumptions, such as whether your CRM's API exposes the fields you need.
Week 3: write it down and plan the build
We write the backlog and specification, finalise the architecture and hosting plan, and lay out the build sprint by sprint. You get a walkthrough of the whole pack and a phased delivery plan. Then you decide, in your own time, with no pressure on the day.
Turning unknowns into decisions before any code is written
Most projects that overrun do so because something nobody understood at the start turned out to matter. Discovery exists to find those things while they are still easy to change on paper. By the end, the vague parts of the brief have become specific, testable decisions.
- Vague requirements become precise ones. "Integrate with the accounts system" becomes "send approved invoices to Xero with these six fields, every 15 minutes, and log failures". A developer can build and test that.
- Risky parts are tested early. If an integration is undocumented or a data migration is messy, a short technical spike finds out in week two, not month three.
- Exceptions are written down. The refund that needs a second approval, the customer on special terms, the job that spans two sites: these are where systems break, so they go into the specification by name.
- Assumptions are visible. Every assumption is listed in the plan. If one turns out to be wrong during the build, both sides can see it and agree the change against a clear baseline.
The result is a build that starts with momentum. The first sprint delivers working screens, rather than a month of questions that should have been asked before.
Data protection and security settled at the design stage
Retrofitting security and UK GDPR into a finished system is slow and disruptive. Designing them in during discovery takes a few hours and shapes everything that follows.
- A personal data map. Which fields are personal data, which are special category (health, for example), where each one comes from and who can see it.
- Roles and permissions. Every type of user, what they can view, edit, export and delete, agreed before the screens are designed.
- Retention rules. How long each kind of record is kept and what happens when the time is up.
- Hosting region. UK or EU hosting chosen and written into the architecture plan, with every third-party service listed.
- Impact assessment input. Where the system processes personal data in a new or high-risk way, we draft the technical sections of your data protection impact assessment.
Our wider approach is set out on the security page. Getting this right at the start means the build team never has to choose between shipping on time and doing it properly.
What the National Audit Office found about deciding too early
The strongest argument for discovery comes from the UK public sector, where IT projects that go wrong are audited and the findings published. In its 2021 report on the challenges in implementing digital change, the National Audit Office's head, Gareth Davies, said there had been "a consistent pattern of underperformance in delivering digital business change, often resulting from decisions on technology being taken too early, before the business problem is properly understood" (NAO, July 2021).
Private businesses make the same mistake on a smaller scale. A director sees a demo, picks a platform or a supplier, and the business problem is fitted to the tool afterwards. Six months later the team is working around the new system the way it used to work around the old spreadsheet.
Discovery reverses the order. Problem first, then process, then the screens, and only then the technology. We cover the other common causes in why software projects fail.
What we need from you during discovery
Discovery is a joint effort. The quality of what comes out depends on access to the right people and information, so we agree this at the start.
- A decision-maker available for 3 to 5 hours a week, who can settle questions of priority without waiting for a board meeting.
- The people who do the work, for 45 to 60 minutes each. Managers describe how a process should work. The people doing it describe how it does work.
- Sample data: exports of the spreadsheets, a few anonymised records from the current system, real documents and forms.
- Read access to the systems we need to integrate with, or at least their API documentation and an admin we can ask.
- Your constraints: deadlines that are real (a contract renewal, a regulatory date), systems that must stay, and anything that is not negotiable.
Being open about constraints early helps more than people expect. It lets us shape a first phase that lands when you need it, rather than designing a perfect system that arrives too late.
Scoping workshop, full discovery or your own specification
Not every project needs the full 2 to 4 weeks. There are three sensible routes, depending on what you already have.
| Route | Best when | What you get |
|---|---|---|
| Scoping workshop | The project is small or well understood, and you need an outline plan for a business case | A half-day or full-day session and a short written summary within a week |
| Full discovery | The project replaces a core process, touches several systems, or needs a firm scope before the build | The full pack above, over 2 to 4 weeks |
| Your own specification | You have a product owner who has written one, and you want a supplier to review it | A gap review and a delivery plan, usually within a week |
If you plan to write the brief yourself, our guide on how to write a software specification covers what to include. We will still review it for gaps before planning the build.
When discovery says do not build
Sometimes the most useful outcome of discovery is a recommendation not to commission custom software. That happens more than agencies admit. If an off-the-shelf product covers 90 percent of what you need, a Xero or HubSpot add-on fills the gap, or the problem is really a process problem, we will say so in the report.
That is still a good outcome. A few weeks of discovery is far better spent than months building something you did not need, and you leave with a clear view of your options. If you are weighing those options already, read bespoke vs off-the-shelf software before the first meeting.
When the answer is to build, discovery also tells you what the smallest worthwhile first release is. For new products that often means an MVP rather than the full vision.