Product research and engineering, for selected partners.
The team that builds Omsome’s own products also works with a small number of partners each year: on the research that decides what to build, and the engineering that builds it.
What we do with partners
An engagement can focus on one of these or connect several. The shape of the work follows the question in front of you, not a fixed package.
Product research
Clarify the problem, study the people and workflows around it, and name the assumptions that need evidence before anyone builds.
Technical exploration
Prototype the uncertain parts, including what AI makes newly possible, and decide what is feasible and worth doing.
Validation
Test the product direction and the riskiest assumptions before a full build turns uncertainty into an expensive commitment.
AI integration
Bring AI into an existing product with costs held to a budget, keys kept out of the code, and people in charge of what agents may do.
Product advisory
Work through hard choices about scope, interaction and technical direction, including what the first version must refuse to do.
Software engineering
Design and build focused software with a small, senior team, carried from decision to delivery and handed over properly.
How an engagement works
Every engagement is agreed in writing before work starts, with a clear scope, fees and timeline.
Introduction
A conversation about the problem in front of you. No brief or deck is needed.
Scope and proposal
A written scope with deliverables, timeline and fees, agreed before any work starts.
Agreement
A signed contract with Omsome covering scope, ownership of the work and confidentiality.
Delivery
Work in milestones, with regular reviews and a single accountable lead from start to finish.
Handover
Code, documentation and decisions handed over in full. The work is yours.
Who we work with
We take on work only where there is room to understand the problem, shape the direction and materially improve what gets built.
A strong fit
- The product direction is still open, and the riskiest questions need answers before a team commits.
- A new capability, often AI, could unlock something useful, but its place in the product is not yet clear.
- You need evidence of demand or usefulness before funding a full build.
- The work is focused enough for a small, accountable team to carry from decision to delivery.
Not a fit
- Staff augmentation: supplying developers to work through someone else’s backlog.
- Building to a settled specification where only execution remains.
- Maintenance and support of existing systems.
- Large, long-running programmes that need big teams and heavy process.
Partner work is made public only when the partner chooses to make it public.