Web and mobile on one core
One data core, one API, two surfaces.
When site and app share accounts, orders and stock, they need a shared core: one API and one team behind both.
One API, two surfaces
When site and app share accounts, orders and stock, the worst decision is to hand them to two different suppliers. Business rules end up duplicated, then divergent, and one customer sees two balances that do not match.
So we build the API first, documented and versioned, and both interfaces plug into it. That is not an architect preference, it is what avoids months of catching up.
The gap between web and app stores
A fix on the web ships the same day. On mobile it goes through Apple and Google review, then through devices actually updating. That gap has to be planned for.
Hence versioning: the previous API version keeps being served while the installed base moves over. Without it, a server-side change breaks the app of every user who has not updated.
Pricing is handled subject by subject, with a short form and a written answer: Quote for a web and mobile project. And to judge on evidence, we show what we run ourselves: our four in-house products.
DX-11
Common questions about a shared core
Do we really need an app on top of the site?
Only if the usage repeats. For occasional consultation a well-built mobile site is enough and costs markedly less to maintain over three years.
Can we start with the web and add mobile later?
That is the order we recommend, on one condition: design the API from the start as if the app already existed. Retrofitting it later costs more than planning it.
Who owns the store accounts?
You do, in your name, and we publish with your credentials. An app published under an agency account becomes a serious problem the day you change supplier.
Reference DX-11
Put a price on it
A short scoping round, a fixed price, a schedule. Tell us the outcome you want, not the solution you picture.