Where to start · Functional aspect · Requirements and architecture
Will we manage to finish what we have been asked for?
Requirements, architecture and integrations checked before the first line of code, with the decisions still open set down in black and white.
10 daysdelivery from kickoff
When you need it
- You have specifications, but a suspicion that they are not as complete as they look.
- You have to integrate with systems you do not control and nobody can say how deep it will go.
- You are about to issue a tender, or answer one, and you need a solid technical scope.
- The supplier said yes to everything and you would like a second reading before signing.
- The proposed architecture is plausible but nobody has put it to the test.
- You have to choose between two technical paths and the discussion has been stuck for weeks.
What we answer
- Are the requirements complete and consistent enough to set time and budget on?
- Where are the ambiguities that would turn into change requests along the way?
- Does the proposed architecture support the loads, the constraints and the expected evolution?
- Which integrations go deeper than they were described?
- Which technical decisions have to be made now and which can wait at no cost.
What we do
- We rebuild the domain model and check that everyone means the same thing by the same words.
- We sift the requirements for completeness, consistency and verifiability.
- We identify the real architectural drivers and compare them with the proposed architecture.
- We define component boundaries and formalise the interfaces (OpenAPI, contracts, events).
- We test the most uncertain integrations in the field, with targeted technical trials.
What you receive
A document of about twenty pages. This is the actual table of contents, not an example.
- Domain model and shared glossary
- Requirements completeness and map of ambiguities
- Inconsistencies found, with the question that resolves them
- Architectural drivers and proposed architecture
- Component boundaries and interface contracts
- Expected quality attributes and how they are measured
- Technical risks and recommended decisions
The decision you will be able to make
Proceed with development · Revise the architecture · Reduce the scope
Knowing the real costs before assigning the work.
And then?
With the requirements sifted and the architecture checked, the scope is ready for a turnkey or fixed-budget project, with predictable time and costs.
Format
- Investment
- A fixed, modest cost, agreed before starting.
- Delivery
- Ten days from kickoff. Kickoff within five working days of confirmation.
- Your time
- About 6 hours in total from your technical and business team, spread over three meetings.
- Scope included
- One application or module, with up to two complex integrations analysed in detail. Beyond this scope we agree an extension.
- For the ten days to be kept
- The existing documentation and access to the test systems arrive by the second day. If something slips, we tell you straight away.
It is an entry format at dedicated conditions, designed to get to know each other by working together. It is not our standard project rate.
What it is not
- It does not produce production code: it produces specifications and architecture on which to write the right code.
- It is not a theoretical opinion: every check is anchored to technical trials and real contracts.
- It does not bind you to develop with us: with this document you can go to tender or hand the work to your usual supplier.