Build AI into the product. Not just the prototype.
A model can produce an impressive answer in an afternoon. A product must solve a problem repeatedly for different users, within real technical and commercial constraints. Marmation brings product judgment, experience design and engineering together to build that product.
What has to be true before this becomes a product?
One valuable customer job must survive real permissions, poor inputs, a failed dependency and the economics of repeated use.
Follow a feature all the way to a reliable outcome.
The feature contract
- Customer job
- Review a supplier submission in the existing product.
- Invariant
- A suggestion never becomes a saved change without the required authority.
- Recovery
- Keep the evidence and review state when a model or API fails.
Frame the job
What decision becomes easier?
User task + acceptance cases
Hold ifNo evidence that the job matters
Prove the slice
Does the hard case work?
Source → review → approved record
Hold ifCorrectness depends on clean inputs
Earn the release
Can it fail without losing trust?
Tenant tests + recovery + cost envelope
Hold ifA timeout can leave an unknown write
Own the system
Who keeps it useful?
Runbook + regression set + handover
Hold ifNobody owns sources or upgrades
A product build has to earn its cost.
Use a mature platform feature when it meets the job. Validate demand before commissioning an application. Resolve undefined security boundaries before committing to production.
Ask to see the difficult journey.
- An authorized user and a user from another tenant
- A missing source, a contradiction and a failed save
- An acceptance set, usage-cost assumptions and a maintenance owner
The complete product engineering argument
For CPO, CTO, VP Product, VP Engineering
The demo is often the easiest part.
The first AI feature is usually persuasive because it shows a possibility. A user uploads a document, asks a question or sees a recommendation. But production brings a different set of questions. Which users are authorized to see which data? How does the feature behave when a source is missing? What happens when the model produces an uncertain response? How does this experience fit an existing workflow that users already know?
None of that is solved by changing the model. It requires deliberate product and systems decisions. A great AI feature needs the foundations of good software: coherent navigation, state, feedback, recoverability, observability, tenant boundaries, performance, release practices and support.
The opportunity is to treat AI as an ingredient in the product, not a separate chat window stapled to it.
The kinds of products we engineer
Intelligent features inside an existing platform
Add assistance, extraction, recommendations or natural-language workflows where they improve a specific job. The design should integrate with the product's data model, permissions, actions and usage metrics. A successful feature does not ask customers to abandon the product experience they already trust.
New AI-native applications
Move from a funded concept to a deliberate software product. We help determine the first customer job, the simplest credible version, model and data dependencies, operating economics and the engineering boundaries required for future expansion.
Modernization of mature product platforms
A legacy product may contain valuable business logic and customer relationships, even when its interfaces or architecture need work. Intelligent capability can be introduced incrementally while protecting the system of record and maintaining backward compatibility.
Product and platform integration
APIs, identity, payment/state workflows, data feeds, internal services and observability make a feature real. These interfaces are often the actual project. We surface them early rather than treat them as a deployment detail.
The questions we answer together
What is the user trying to accomplish? What changes in the workflow if AI is added? Which parts must be deterministic? What should happen if confidence is low? What data may the system access? What is an acceptable per-request cost at projected usage? How will we know the capability is actually being used and is improving the product?
We turn those questions into a product brief, acceptance criteria and implementation plan. Product strategy is not an open-ended consulting service. It establishes decisions that the engineering team can use.
A practical example
Imagine a B2B software platform that wants to help customers review complex supplier documents. A superficial solution uploads a PDF and produces a summary. A real product must identify the document's relevant sections, preserve source references, compare extracted facts with the customer's records, present contradictions, ask for human confirmation and store the result in the existing workflow.
The difference is product engineering. The AI output is one step in an experience involving identity, state, data contracts, user judgment and recovery.
How we work
Frame: business job, target user, UX, success criteria and integration constraints.
Architect: evaluate managed services, models, deployment patterns, database and tenancy requirements. Buy commodity components when it makes sense.
Validate: build a representative vertical slice with testable data and clear negative cases.
Engineer: create frontend/back-end features, APIs, integrations, evaluation and release controls around production behavior.
Transfer: document the system, its limits, dependencies, ownership and maintenance path.
What a good outcome looks like
We should be able to demonstrate the feature against the intended user job, measure meaningful adoption or task outcomes once deployed, show what it does when inputs are poor, explain operational cost and provide a credible path for maintenance. A one-off conversation with an LLM is not sufficient evidence.
When not to build
If a mature platform feature meets the customer's requirements, implementing it will usually be more sensible than commissioning a custom replacement. If product demand has not been established, a discovery or validation sprint may be a better investment than a full application. If security boundaries cannot be defined, that risk must be resolved before production.