Technology consulting
Technology consulting and architecture review
An outside read on the system, the architecture or the plan, before you commit to it.
Some decisions are worth a second opinion because reversing them is far more expensive than making them. Committing to a platform, signing a multi-year vendor contract, or deciding to rebuild a system that still works are all in that category, and all are usually decided with information supplied by whoever benefits from the answer.
We read the system, the architecture or the proposal, and report what we find. That includes the things a vendor will not volunteer: where the lock-in sits, what the integration will actually cost, which parts of the estimate are load-bearing, and what happens to your data if the relationship ends.
The output is a document you can take to a board or a procurement committee, with the reasoning shown rather than a conclusion asserted. Where the honest answer is that your current system is fine and the money is better spent elsewhere, that is what the report says.
What you get
- Architecture and code review
- Build, buy or extend analysis
- Vendor and platform assessment
- Delivery roadmap and resourcing plan
Who this is for
- Boards and procurement committees
- CIOs facing a large commitment
- Organisations mid-way through a troubled project
How the engagement runs
Six steps, in this order.
Skipping one of these is how projects end up rebuilt. The order matters more than the ceremony.
- 01
Consultation
We sit with the people who do the work and find out what actually happens, including the workarounds nobody documented.
- 02
Planning and proposal
Scope, timeline and cost in writing, with the assumptions listed. If something is unknown, it is named as unknown.
- 03
Design and development
Data model first, then interface. You see working software early and often rather than a demo at the end.
- 04
Testing and refinement
Functional, load and user acceptance testing. Findings go on a list that gets closed, not a list that gets discussed.
- 05
Implementation and integration
Migration, integration with existing systems and a cutover plan that accounts for the day the old system is switched off.
- 06
Training and support
Your team is trained on the system they will use, and we stay on for maintenance, updates and the questions that arrive in month three.
Questions
Asked before we start.
Something not covered here? Email us and a person will answer.
Will you recommend your own products?
Only where they genuinely fit, and we will say so explicitly when a recommendation is for something we sell. If a competitor's product is the better answer for your case, the report says that. A review whose conclusion was decided in advance is worth nothing to you and damages us.
How long does a review take?
An architecture or code review is typically two to four weeks depending on the size of the system. Vendor assessments depend on how quickly the vendors respond to questions, which is itself informative.
Can you review a proposal from another supplier?
Yes, and it is a common request before a large contract is signed. We assess the technical approach, the estimate and the commercial terms that affect your exit, and flag what we would want clarified before signing.
Scoping
Send us the process that keeps breaking.
A short description is enough to start. We will come back with whether it is a product, a build, or something you can fix without buying software.
Nairobi office
10th Floor, Applewood Adams, Ngong RoadNairobi
Kenya
- Phone
- +254 701 684 754
- Hours
- Mon–Fri, 08:30–17:30 EAT