Sound familiar?
- You know what is wrong but not exactly what to build
- Previous projects ran over because the scope kept changing
- Quotes from suppliers vary hugely because each guessed differently
- Different people in the business want different things from the same system
- You are not sure whether the systems you use have the APIs you need
- You need a clear plan and cost before you can get budget approval
Key facts
- Discovery is how we can quote a fixed price rather than an estimate
- Outputs include process maps, user roles, a data model, an integration list, wireframes and a risk register
- Big builds are split into phases, each delivering something usable
- The first phase is kept as small as possible while still being useful
- You own the discovery documents and can use them with any supplier
- Integrations are checked against real API documentation, not assumed
- We will tell you during discovery if off-the-shelf software is a better fit
Why discovery comes before a fixed price
Software projects go over budget for one main reason: the work turned out to be different from what was quoted. Usually nobody was being careless. The quote was based on a short brief, and the real requirements, edge cases and integration problems only showed up once building started.
Discovery moves that learning to the start, when it is cheap. We dig into the processes, data and systems involved until we understand them well enough to commit to a fixed price for a defined scope. That is how dijitul developments can quote fixed prices at all: we only quote once we know what we are quoting for.
What happens during discovery
- Free chat. We talk through the problem, the goal and any constraints. If bespoke software is not the answer, we say so here.
- Workshops and interviews. We talk to the people who will use the system, not just those commissioning it: the office team, field staff, finance and, where relevant, customers.
- Process mapping. We map how work happens now, where it goes wrong, and how it should work, including exceptions and approvals.
- Systems and data review. We look at the systems involved, sample data and the actual API documentation for anything we will integrate with, such as Xero, Shopify, Microsoft 365 or your ERP. Limits like API rate limits or missing endpoints are found now, not halfway through the build.
- Wireframes. Key screens are sketched or prototyped so everyone agrees what the system will look like and do.
- Scope and phases. We write it up and agree what is in phase one, what comes later and what is out of scope.
What you get
At the end of discovery you have a written scope you can read and challenge, not a technical document only a developer understands. It includes user roles and permissions, process maps, a phased feature list, a data model, an integration plan, wireframes, and a register of risks and assumptions. It also includes our fixed-price quote for phase one and an outline of later phases.
The documents are yours. If you decide to build with another supplier, or internally, you can take them with you. Several suppliers can quote against the same scope, which makes their prices comparable.
Keeping phase one small
The most useful thing discovery does is decide what not to build yet. We aim for a first phase that solves the most painful part of the problem, gets used by real people, and teaches everyone what the later phases should be. A smaller first phase is quicker to deliver, lower risk and easier to quote accurately. Features that seemed essential in a workshop are often less important once people are using the first version, and the budget is better spent on what they actually ask for next.
For new products, this is the same thinking as an MVP.
Discovery for existing systems
Discovery is not only for new builds. When the project is to replace, upgrade or extend a system you already have, discovery also covers what the current system really does. We look at its database, reports and integrations, and talk to the people who know its quirks, because old systems hold business rules nobody wrote down. We take sample data to check quality and plan the migration, and we note which features are used daily and which have quietly been abandoned. That often shrinks the scope considerably, and it means the new system does not lose something important that only came to light after go-live. For older software, this work often happens alongside a code audit.
Changes after the quote
Requirements will change during a project, because businesses change. A clear scope makes that manageable. When something new comes up, we check it against the agreed scope. If it is a clarification, we just do it. If it is new work, we quote it separately at a fixed price and you decide whether it goes into the current phase, a later one or not at all. No surprise invoices.
Ready to start? Book a free chat, or read how we work for the whole process from first conversation to handover.
What we deliver
- Process maps of how work happens now and how it will work with the new system
- User roles and permissions
- A prioritised feature list split into phases
- A data model and integration plan with the APIs confirmed
- Wireframes or a clickable prototype of the key screens
- A risk and assumptions register
- A fixed-price quote for phase one and an outline for later phases
How it works and what it costs
Every project gets a fixed-price quote after a free initial chat and a short scoping stage. You own the code and the data.
Free chat
Tell us the problem in plain English: what you do now, what goes wrong and what "better" looks like. No charge, no obligation.
Scoping
We map the processes, systems and data involved, agree what is in and out, and write it down so there are no surprises.
Fixed-price quote
You get a fixed price for the agreed scope, or a phased plan for bigger builds, so you can start small and prove it works.
Build and test
We build in short stages you can see and try, test against real data, then go live carefully with a rollback plan.
Hand over and look after
You own the code and the data. We can host it, support it and keep improving it, or hand it to your own team.
Frequently asked questions
What is a software discovery phase?
Discovery is a structured stage at the start of a project where we work out exactly what needs building: users, processes, data, integrations, screens and risks. dijitul developments uses it to produce a written scope and a fixed-price quote, so the price reflects the real work rather than a guess.
Why can't you just give us a price now?
We can give an indication in the free chat, but a fixed price needs a defined scope. Without discovery, any supplier is guessing, and guesses either include a large safety margin or lead to extra charges later. dijitul developments prefers to quote once it knows what it is quoting for.
Do we own the discovery documents?
Yes. The scope, process maps, data model, wireframes and other outputs are yours. You can use them to build with dijitul developments, with another supplier or internally, and several suppliers can quote against the same scope.
Who from our business needs to be involved?
Someone who can make decisions, plus the people who will actually use the system day to day. Their knowledge of exceptions and workarounds is what makes the scope accurate. dijitul developments keeps workshops focused so it does not take people away from work for long.
What if discovery shows we should not build bespoke software?
Then we tell you. Sometimes the answer is an off-the-shelf product, a simple integration between systems you already have, or a change of process. dijitul developments would rather give you the right answer than a bigger project.
What happens if requirements change after the fixed-price quote?
Clarifications within the agreed scope are covered. Genuinely new work is quoted separately at a fixed price, and you decide whether to add it now, schedule it for a later phase or drop it. You never get an unexpected invoice from dijitul developments.
Related
Tell us what you need to build
Free chat, clear scope, fixed-price quote. You own everything we build.