Where to start
If the problem is vague or the requirements are unclear, the best way to begin is not to start writing code, but to gain clarity with a preliminary study.
Here you will find some of the ones we are asked for most often.
“I would like to build a new piece of software but I do not know where to start.” · “The budget for this project has already been set. I do not know if it is enough.”
Are we building the right thing?
Before investing in development we line up the problem, the expected value and the priorities. You come out with an ordered backlog, a direction you can defend in front of the people who make the decisions, and a budget estimate to reason about.
“At the beginning the requirements seemed clear. After a while they no longer were.”
Will we manage to finish what we have been asked for?
Before moving on to writing code we check architecture, requirements and integrations, and we put the technical decisions still open in writing, so that nobody discovers them halfway through the project.
“The project has started but I cannot say how far it has got.”
Is the project under control?
A clear picture of time, costs, dependencies and responsibilities, written to help both the team and the people who make the decisions.
“This software works, it is just that nobody wants to touch it.”
Can we still evolve this system?
We estimate what it will cost you to evolve the software you already have, where it pays to intervene and what is better left as it is.
How does the analysis work?
- Investment
- The cost is fixed and modest, agreed before starting.
- Delivery
- Ten calendar days from kickoff, which takes place within 5 working days of confirmation.
- Your time
- About 6 hours in total, spread over three meetings with the people in charge.
- What you receive
- A structured document of about twenty pages, written to be read even by those who did not follow the analysis, with a diagnosis and an indication of the next step.
- The decision
- At the end you have what you need to decide whether to proceed, change direction or stop, before committing the development budget.
What it is not
- It is not a formal audit and it is not a review of people's work.
- It is not a sales proposal dressed up as an analysis to sell development days.
- It does not produce code, but the basis for writing the right code.
- It does not oblige you to continue development with us.
The document stays yours
None of these analyses ties you to us for development: the document is yours and remains valid even if you then hand it to another supplier or to your in-house team.
And no analysis is compulsory: if the picture is already clear, we can start directly with development.
Not sure which one you need?
We have prepared a short three-minute survey that brings your situation into focus and points to the step that makes most sense right now. Or, if you would rather talk it over, write to us. It will not be a salesperson who replies, but an engineer.