Included in a typical proposal
- The workshops and review days in the proposal.
- A written options or roadmap document.
- A readout meeting.
SOFTWARE DEVELOPMENT
Clarify a software decision before committing to implementation. Use a focused review or discovery engagement to turn business requirements into practical options.
WHAT THIS SERVICE IS
Software consulting is a bounded piece of advice: a discovery workshop, a technical review, an options paper, or a delivery roadmap. It exists so you can make a decision before you fund a build. It is not unpaid pre-sales theatre, and it is not a disguised implementation team that starts coding on day two unless you buy that.
Good consulting output is specific: three options, what each needs from you, and what would make the author change their mind. Bad consulting output is a slide of trends. You will not receive the second from this page.
Access to the current system, the people who use it, and any constraint (a deadline, a regulator, a parent-company standard) makes the work cheaper and less speculative. If you cannot grant access, the paper will be labelled as such.
A CLEAR PICTURE
Otherwise the workshop wanders.
Systems, samples, constraints.
Including “do nothing yet”.
So it can be used, not filed.
WHO IT IS FOR
Owners choosing between build, buy and wait; IT managers who inherited a mess; and teams that need a second reading of a vendor proposal they do not trust.
TYPICAL SCOPE
Process, stakeholders, and the outcome that would count as success. Conflicts are written down rather than smoothed in the room.
Architecture, code sample, or integration constraints, at the depth you fund. A two-day review will not read every line. We will say what we did not open.
Usually build, configure a product, or integrate. Costs are ranges only when we have enough input, and never invented AED figures on the website. Trade-offs are the point.
Suggested sequence, dependencies, and what to stop doing. A roadmap is not a contract to implement. Implementation is a later proposal if you want it.
INCLUDED AND QUOTED SEPARATELY
AFTER HANDOVER
The document is yours to circulate. Underlying notes that contain other people’s systems may need redaction if you share widely. We will say what is confidential to the workshop.
If you later ask us to implement, the consulting paper is the starting brief, not a frozen specification. Reality will still move.
PRACTICAL NOTES
A useful paper states what would change the recommendation. If a constraint is unknown — you have not opened the code, you have not seen the contract — the option is labelled as conditional. That is more helpful than a confident diagram of a system we were not allowed to see.
Workshops with only directors produce a clean story that users later contradict. Ask for two practitioners in the room. If politics forbids that, the document will say the user path was described second-hand. You can still decide; you should know the quality of the evidence.
PLANNING THE WORK
We will compare against your requirements. We do not run a hidden league table. If we would also be the implementer, we will say so you can weight that.
Yes, with a thinner artefact. Some decisions need more reading time. We will recommend a length rather than stretch a day into theatre.
We can review and list risks. Certification, insurance and legal sign-off are not this service.
CONNECTED SERVICES
LET’S BUILD WHAT’S NEXT
Tell us what you want to improve, build or simplify. We’ll help you define a practical way forward.
Discuss your project