First, I define the right problem
A new product often starts with “Which technology should we use?” I first clarify whose task you want to make easier, how it works today and how success will be measured. I turn requirements into user flows, decision points and acceptance criteria.
The work defines the first meaningful release without inflating scope. It makes uncertainty, dependencies and assumptions that need early validation visible.
I make technical decisions in business context
Architecture and technology choices are not about using fashionable tools. Team skills, data sensitivity, integrations, expected usage, release frequency, running costs and maintenance capacity all matter. I record alternatives and trade-offs clearly and avoid solutions that work today but cannot change tomorrow.
- Product scope, user journeys and first-release priorities
- Application architecture, data boundaries and integration approach
- Technology stack, team capacity and long-term operations
- Requirements for testability, accessibility, security and observability
Who is it for?
- Founders and product owners defining a new product’s scope and technical foundation
- Managers who want to understand technical risks before adding a module or integration to an existing application
- Software teams with a clear business need who want to test architectural choices and priorities
- Companies reassessing a live product’s performance, maintainability or user experience
Consultancy is not simply hiring an outsourced developer
This work is about improving product and technical decisions, rather than adding another person to a long task list. I can join the team for code, test or architecture reviews where useful, with the aim of leaving lasting capability. I agree the scope and working arrangement in the first conversation.