{"id":988617,"date":"2026-10-04T17:00:00","date_gmt":"2026-10-04T17:00:00","guid":{"rendered":"https:\/\/croncodestudio.com\/en\/?post_type=croncode_post&p=988617"},"modified":"2026-09-08T22:58:43","modified_gmt":"2026-09-08T22:58:43","slug":"client-app-and-internal-tool-same-codebase-risks","status":"publish","type":"croncode_post","link":"https:\/\/croncodestudio.com\/en\/journal\/client-app-and-internal-tool-same-codebase-risks\/","title":{"rendered":"Client App and Internal Tool: Same Codebase Risks"},"content":{"rendered":"
\n

A client App Store app and an internal tool often want the same nouns: orders, bookings, garments, cases. Sharing a repo looks efficient. It becomes expensive when a store review, a staff permission, and a weekend hotfix share one branch. At Croncode<\/a> we will share models and APIs on purpose. We will not hide an admin panel inside a consumer target because it felt faster on Friday. Dual-track culture: products and client software together<\/a>.<\/p>\n

\n

A shared codebase for a store app and an internal tool saves days and leaks risk: secrets, review surface, and a release train that cannot move independently. Share rules, not a blob.<\/p>\n<\/blockquote>\n

What is actually being shared?<\/h2>\n

Three layers. The object model. The API. The UI targets. Sharing the first two is often right. Sharing the third is where staff screens, debug flags, and API keys wander into a TestFlight a stranger can install. Security questions: before you sign<\/a>. Account ownership: App Store account<\/a>.<\/p>\n

Consumer jobs stay consumer: YourStyle<\/a>, Numira<\/a>, Spylie<\/a>, Luviport<\/a>. An operator console is a different user. Catalog: what Croncode builds<\/a>.<\/p>\n

Which risks show up after the first shared release?<\/h2>\n
    \n
  1. A store reviewer finds a hidden admin route or a debug menu.<\/li>\n
  2. A staff token ships in the consumer binary.<\/li>\n
  3. A hotfix for the tool blocks a crash fix for the app. Crash questions<\/a>.<\/li>\n
  4. Analytics from staff usage pollutes consumer funnels. Analytics<\/a>.<\/li>\n
  5. Deletion scripts miss the tool\u2019s copies of the same person. Deletion<\/a>.<\/li>\n<\/ol>\n

    Lean teams feel this more: small team, multiple products<\/a>. Shipping: Istanbul shipping<\/a>.<\/p>\n

    When is one repo still the right call?<\/h2>\n\n\n\n\n\n\n\n\n
    Setup<\/th>\nOne repo<\/th>\nSplit<\/th>\n<\/tr>\n<\/thead>\n
    Shared schema, two targets, two signing identities<\/td>\nYes, with gates<\/td>\nIf gates fail<\/td>\n<\/tr>\n
    Staff UI inside the consumer app<\/td>\nNo<\/td>\nYes<\/td>\n<\/tr>\n
    Different legal entities<\/td>\nRarely<\/td>\nYes<\/td>\n<\/tr>\n
    Marketing WordPress site<\/td>\nNo<\/td>\nYes. Elementor<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Handover must list both trains: handover<\/a>. Sprint demos should not mix staff and consumer unless that was the increment: sprint demo<\/a>.<\/p>\n

    How do we write the rule in the contract?<\/h2>\n

    Name the targets. Name who may hold staff credentials. Name the store bundle ID owner. Name whether TestFlight may include debug menus. Quote packet: what to send<\/a>. Commercial: fixed price vs retainer<\/a>. We will not build a hidden admin in a consumer listing: will not build<\/a>.<\/p>\n

    Founder: Goktug Unver<\/a>. Co-founder: Yusufhan Sokur<\/a>. Team: Ozgur Ismet Ozkan<\/a>.<\/p>\n

    What mistakes look like efficiency?<\/h2>\n