Eleven products, seven of them live on a store, all designed, built, submitted and maintained by this studio. Nothing on this page is client work, because we have been our own client - which is why we can show you the unflattering parts of a launch as well as the screenshots.
What people arrive with
The gap between a working build and an approved listing is where most first apps stall: signing, identifiers, privacy declarations, age rating, screenshots at the right sizes, a review that comes back with a guideline number. We have been through that queue repeatedly, including the rejections, so the route is a checklist here rather than a surprise.
An MVP built to be thrown away usually is not, and then every later feature pays for the shortcut. Our own products are built on the assumption that we will still be inside them next year, because we will be - there is no handover to hide behind.
Accounts, guest-to-account migration, subscriptions, entitlement state, restoring a purchase on a second device, and what the app does when the network is gone. This is the work that makes a release late, and it is the work we have already done more than once.
What the work includes
Scope is where a project is decided, so this list is specific rather than reassuring.
Native where native is the right answer and cross-platform where it is not. Our own catalogue runs on both sides of that line, deliberately, so the choice is made per product rather than per studio preference.
Play Console setup, app signing, internal and closed testing tracks before anything is public. Several of our products sit in closed testing right now and this site says so, because that is what the track is for.
Hosted database with authorisation rules, private file storage, anonymous sign-in, and the migration that moves a guest account onto a real one. Also the decision not to have a backend: a product that works offline with no account is a stronger product when it can be, and several of ours are.
Store products, offerings, entitlements, and the server-side state that has to agree with them. Verified the only way it can be - a real purchase on a real device moving a real account between plans, with the resulting entitlement rows kept as evidence.
Sign-in that does not block the first run: anonymous first, upgraded later, with the guest data carried across. And where a product has no business knowing who you are, no sign-in at all.
Automated gates first, then a person. Small, common and tall phones, tablets, right-to-left layout, German expansion - the matrix is a document, the runs are recorded, and a build that has not passed physical-device testing is described as one that has not.
Listing copy, localisation, screenshots generated from the shipped build rather than from a mockup, privacy answers that match what the app does, and a store status re-checked against the store instead of assumed from the repository.
How it runs
Not a process diagram written for this page. It is the production loop the studio already runs, which is why it has a measure step and a human gate in it.
Evidence
Everything shown as evidence on these pages is a NOVEMADE product - our idea, our money, our name on the listing. There is no client logo wall here, no testimonials and no case-study metrics, because there have been no clients to take them from. What there is instead is software you can open.
1002 early-learning activities for two- to six-year-olds, voiced in 29 languages.
Sprint analysis, training and nutrition in one app, with the form analysis on the phone.
Design a tattoo, turn it into a working stencil, and see it on your own skin first.
Check it yourself
A web recreation of one Didi flow with sample household data, not the app itself. Didi’s logic is bound to its native UI layer and there is no engine boundary to expose, so what you are using is the interaction, not the product.
Where this stops
We do not take over somebody else’s codebase sight unseen, and we do not quote a mobile build from a one-page brief. The first thing we ask for is the hardest screen in the product, because that is where the estimate actually lives.
Also from the studio
Collaborate
Publishing, partnerships, investment, or a technical conversation about how we build. Tell us which one and we will skip the rest of the form.
