# Product Engineering

> New product builds across web and mobile, delivered by an AI Pod against a committed scope, starting with a complete end-to-end loop.

Source: https://www.koombea.com/capabilities/product-engineering/

---

Most first phases deliver scaffolding and call it progress. Ours delivers a complete end-to-end product loop you can put in front of a real user.


## The problem

Product engineering services are the largest thing a Pod does: taking a product from an idea or a prototype to something running in production with real users on it. Web, mobile, or both, on whatever stack the problem actually calls for.

The part that matters is sequencing. We insist that Phase 1 is a complete loop, meaning a user can get in, do the core thing the product exists for, and get a result. Not a login screen, a design system, and a promise.

That constraint is unpopular in planning meetings, and it is the single biggest reason projects here do not quietly die in month four. A loop can be tested, demoed, and funded. Scaffolding can only be described.

- Phase 1 is a usable end-to-end product, never a stub
- Native and cross-platform mobile, decided by the requirement rather than by preference
- Web applications, APIs, and the infrastructure to run them
- Estimated in story points and priced before work begins

## What this covers

- **Mobile products**: Native iOS and Android where the experience demands it, cross-platform where it does not.
- **Web applications**: Long-lived systems with real users, real data, and real uptime expectations.
- **MVPs that survive**: A first version scoped to prove the thing, not to impress a slide.
- **Performance under load**: Built to hold up at the volume you expect, verified before launch.
- **Secure by default**: Authentication, authorization, and data protection as part of the build.
- **Analytics from day one**: You cannot iterate on a product you cannot measure.

## Native or cross-platform. The requirement decides.

This is the first real fork in a mobile build, and it is usually settled by preference rather than by evidence. Here is how we settle it.


| | Cross-platform | Native |
|---|---|---|
| Choose it when | The product is forms, lists, content and standard navigation, and it needs to exist on both platforms at once | The experience is the product, or you depend on hardware and OS features that move fast |
| Point cost | One codebase, so roughly one build plus platform-specific polish | Two codebases for shared scope, priced accordingly |
| Hardware access | Fine for camera, location, push and biometrics | Required for Bluetooth, NFC, payment terminals, background behavior and deep OS integration |
| Design latitude | Good, until you want motion and gesture work that fights the framework | Total |
| Where it fails | A team picks it for cost and then specifies a native-feeling product | A team pays twice for a product where nobody could tell the difference |
| Our default | Where the requirement genuinely allows it, because the saving is real | Where the requirement demands it, and we will say so plainly |

## What drives the estimate

We cannot price a paragraph, but we can tell you exactly what moves the number, because a story point is sized on functional surface area, integration count, and the test coverage needed to ship it with confidence.

So the things that make a product expensive are rarely the things clients expect. Screen count matters much less than the number of distinct states each screen has. One more third-party system to reconcile against costs more than several more list views. And a role model with four permission levels is a different product from the same features with one.

We would rather show you these levers during scoping than discover them in month three. It is also why Phase 1 is scoped as a complete loop: a loop is the smallest thing whose real cost we can prove.

- Distinct states per surface, not screen count: empty, loading, partial, error, offline, permission-denied
- Integration count and how badly each partner system behaves under failure
- Roles and permissions, which multiply test surface faster than features do
- Regulated data in scope, which raises the coverage bar rather than the feature count
- Offline or real-time requirements, which change the architecture rather than adding to it

## What this looks like in your industry

The engineering is the same discipline. What changes is which failure mode is unacceptable, and that changes what we build first.

- Health Services: Clinical workflow, HIPAA-ready handling, and audit trails built as you go rather than reconstructed.
- Payments and Lending: Idempotency and reconciliation from the first commit, because a double-post is not a bug you patch later.
- Industrial and Field Service: Offline-first as an architecture, not a cache. Crews work where connectivity does not.
- Retail and Commerce: Native storefronts and commerce platforms, including StorefrontOS as a starting point.
- Technology and SaaS: Multi-tenant isolation and platform APIs other people build against.

## Questions worth asking

### Can you work on our existing codebase rather than starting fresh?

Yes, and most engagements are this rather than greenfield. We start with a paid discovery pass to inventory what is there, because estimating work on a codebase we have not read is guesswork dressed up as a number. That pass produces the work breakdown the build is priced from.
### Who decides the stack?

We propose it and you approve it, and we record the reasoning so the decision can be revisited rather than re-argued. It is chosen from the requirement, not from what we most enjoy writing.
### What if Phase 1 proves the idea does not work?

Then it did its job, and it cost you one phase instead of a year. That is the entire argument for insisting Phase 1 is a working loop rather than a foundation. Scaffolding cannot fail informatively.
### Do we get the code as we go, or at the end?

As we go. You have repository access throughout, and formal transfer of source and pipeline access is a gate on Phase 1 acceptance, not a favor at the end.
### Can you take over a project another partner started?

Often, and we will tell you honestly when a rewrite is cheaper than a rescue. The discovery pass exists to answer that question before either of us commits to it.

## Products in market, with published results

Luna went from nothing to a native app in market in three months. FlightLogger tracks over 1,500 airlines with worldwide coverage of over 30,000 airports.