Product development: from the decision about what to build to software your team can run
We build products for you, beginning where the doubt is greatest. The work is finished when your own engineers have changed the product and shipped the change.
Who this is for
Product leaders, CTOs and founders inside larger businesses who need a product shaped, an AI capability added, or a platform engineered, without first building a team to do it.
In brief
Yes. XONIK builds products for founders, product leaders and CTOs, and begins at the stage where the doubt is greatest: what to build, whether an AI feature can be good enough, or how to engineer a platform your own team can run. Each stage is scoped and bought on its own.
How a product moves
Evidence first, then the smallest product that proves it.
On this page
Where does your product stand today?
Founders and product leaders usually arrive with a budget and a build in mind. Our first question is a different one: what is the least certain thing about this product? Where the doubt is about the buyer, the work starts in discovery. Where it is about whether an AI feature can be good enough, it starts with the evaluation. Where the design is settled, it starts in engineering, with your engineers beside ours.
| Where you stand | Start with | What you bring to it | What you hold afterward |
|---|---|---|---|
| A roadmap of requests, and no evidence from the people who would pay | Product Strategy and Discovery | Access to users and budget holders, and a product owner who can cut scope | A claims sheet, a research record and a scoped first release |
| The product depends on AI and nobody has defined a good answer | AI Product Development | Real examples of the task, and domain experts who will judge the output | An evaluation set with scoring rules, guardrails and monitoring thresholds |
| The design is settled and you need a platform, an application or integrations | Digital Product Engineering | An engineering lead, and engineers who join the work early | A live product, a run book and releases your own engineers have shipped |
| An offer no buyer has seen, and no decision yet to build | Product Innovation, under consulting | Introductions to buyers, and willingness to hear a no | A paper that says build, change or stop |
How the stages depend on each other
Discovery and the evaluation come before engineering because everything built afterward is judged against them. The AI work and the engineering often run together, so the AI ships as part of a product that can be released, rolled back and monitored like the rest. You can enter at any stage, and we tell you when the stage you chose leaves your largest risk untouched.
A product is finished when your own engineers have changed it and shipped the change.
How a build engagement starts and ends
- 01
A conversation about the product, not the stack
With the founder, product leader or CTO who will answer for it: who it is for, what exists, what has been tried and what has been promised to whom.
- 02
A decision about where to enter
We name the stage where the doubt is greatest and write down what would settle it. Sometimes the decision is that the product should not be built yet.
- 03
A scope for that stage only
With the artifact each stage must produce before the next is agreed. Later stages are not committed in advance.
- 04
Work in your repositories and your tools
Research, evaluation sets and code stay where your people can read them as the work goes.
- 05
A handover you test
Your engineers make a change and ship it while we watch, and the run book is used before it is trusted. Then the engagement closes. Further work is a new scope.
When to hire a firm to build, and when to build the team first
It fits when
- The product has to exist before you can justify the team it would take.
- At least one engineer or technical lead on your side can join early and will own it.
- You work inside a larger business and the product must clear procurement and security review.
Look elsewhere when
- You want to hand over ownership of the product for good. We build for handover.
- Nobody on your side can say no to a feature.
- A packaged product would do the job. We help you buy it instead.
What you give up is control of the daily pace. The work moves at the speed of agreed scopes and your decisions, so expect to spend as much time deciding as reviewing.
A pattern we are called into
A property business, a tenant portal and an assistant nobody had tested
A real estate business inside a larger group has funding and a vendor's quote for a tenant portal with an AI assistant for maintenance requests. The quote lists screens. It says nothing about who will use the assistant, what a correct answer is, or who changes the portal after launch.
- Discovery. Time with tenants and maintenance coordinators shows the delay sits in coordinators decoding requests. The first release becomes request intake with triage help.
- Evaluation. Coordinators mark real requests with the right category and urgency. A model that reads a gas smell as a billing query fails, however fluent it sounds, and that case enters the test set first.
- Engineering. Intake connects to the work-order system through one named interface, and a failed hand-off raises an alert instead of vanishing.
- Handover. A group engineer adds a request category and ships it, and the coordinators' lead reads the monitoring thresholds with us.
Where it endsThe portal does less than the quote promised, and it is used. Its owner sits in the property business, and a fault in the triage shows on a dashboard before it shows as a complaint.
Before you start
Useful first steps.
Questions
What do founders and CTOs ask before they commission a build?
Do we need an engineering team before we hire you to build?
No, but one engineer or technical lead on your side must join early enough to own the result. A product can exist before its team does, provided someone learns it as it is built.
Can we hire you for one stage and not the others?
Yes. Each stage is scoped and bought on its own, and none commits you to the next. If the stage you chose leaves your largest doubt untouched, we say so before you commit.
Do we own the research, evaluation sets and code you produce?
Ownership is set in the statement of work, and your counsel reviews it first. The working materials are kept in your accounts as the work proceeds, so there is nothing to collect when the engagement closes.
Have a product decision to make?
Describe what you are weighing in a few lines. A senior practitioner replies with a suggested first conversation.