App Store Products and Client Software
A product-and-client studio runs two kinds of work in one shop. One backlog is the company’s own App Store apps. The other is software a client will own. The craft can be shared. The calendar cannot be a blur. This article is about that dual track. It is not about how a lean team allocates designers in the abstract. For that resource model, read small team, multiple products.
A studio can ship its own App Store apps and client software if backlogs stay separate and standards stay shared. Mixing the calendars is how both sides slip.
Why keep both tracks?
Own products keep the team honest. You cannot hide from App Review, empty states, or a store screenshot that does not match the binary. Client work pays for depth in ecommerce, operators, and integrations you would not fund as a consumer experiment. Croncode does both. The public consumer set is YourStyle, Numira, Spylie, and Luviport.
This is how a studio becomes an ecosystem without pretending every app must share a login. The wider idea is in from single-product wins to ecosystem building. Dual track is the operating version of that idea.
What must stay separate?
- Roadmaps. A client deadline does not silently eat a store fix.
- Accounts. Client Apple orgs stay in the client’s name.
- Data. No client data in a consumer prototype. No consumer analytics in a client demo.
- Invoices. Time spent is labeled. Goodwill is not a line item you discover later.
If those four blur, you do not have two tracks. You have one stressed queue. Hiring and model choice: studio vs freelancer vs agency.
What should stay shared?
| Shared | Why | Risk if not shared |
|---|---|---|
| UI tokens and review habits | Quality does not fork | Client work looks like a different company |
| Localization practice | TR/EN is a default | Last-week string dumps |
| Security basics | Keys and logs | A leak on either track |
| Postmortems | The same mistakes | Repeating a store rejection |
Shared taste is why client UI can look as quiet as a consumer app. See UI/UX for premium consumer apps and reducing digital noise.
When should you refuse a client?
Refuse when the work would force you to abandon a store-critical increment with no written pause. Refuse when the client wants you to keep their bundle ID. Refuse when the brief is only “make it AI” with no job. Briefing: how to brief an AI app studio. Quotes: what to send.
What mistakes look like ambition?
- Using a client as a beta for your consumer app: that is a conflict.
- Staffing both tracks with the same week and no buffer: both will slip.
- Hiding own-product time as research on an invoice: do not.
- Copying a client feature into a consumer app without a rights check: write the contract.
People: Goktug Unver, Yusufhan Sokur, Ozgur Ismet Ozkan. How we ship from Istanbul: the Istanbul shipping piece. Index: Journal.
A useful weekly artifact is a two-line status: store increment this week, client increment this week. If one line is empty, say so. Empty is better than a blended sentence that hides a slip. Clients can ask for that status. Founders inside the studio should read it too. It is how a lean team stays honest without a program management office. Hiring still uses named people: Istanbul checks. Catalog of what we ship: what Croncode builds.
Frequently asked questions
Will my project be paused for YourStyle?
Not if the calendars are separate. Ask for the named people and the written pause rule. If nobody can name them, you are in a blur.
Do I get the same UI quality as the consumer apps?
You should get the same standards. You will not get the same screens. Your object is different.
Can a freelancer shop run this dual track?
Rarely. One person can moon-light. They cannot hold two honest calendars for long. See the model comparison linked above.
Is this the same as an agency with a lab?
A lab that never ships a store listing is a slide. Own products that are live are the test.
How do I start as a client?
Send the quote packet and the first job. Start at croncodestudio.com/en.
