DevDeer TechLoading
Engineering
Kaies Mahmud Nehal2 min read
Our platform is not one app. It is a public site, a client dashboard, an admin dashboard, a team dashboard, and a mobile app. Five surfaces, one product.
The obvious risk is drift. A blog renders one way on the website and another way in the app, and a bug fixed in one place lives on in four others. Here is how we keep them in line.
Each surface has its own codebase, its own release schedule, and its own developer working on it. Small differences pile up until the same content looks and behaves differently depending on where you open it.
Every inconsistency becomes a bug report. Every fix has to be repeated in each place. Over time, more effort goes into keeping surfaces aligned than into building new features.
Certain files, like how rich text renders and how status badges look, live in one canonical repo. A script copies them into the other repos so they stay byte for byte identical.
When a shared piece changes, we change it in one place and run the sync. No hunting through five codebases.
Content is authored in a rich editor. Rather than trusting each client to process it correctly, the server does the heavy lifting. It takes what the editor sends, cleans it, and derives the plain text, table of contents, and reading time centrally.
Web, dashboards, and mobile all receive the same output. No client re-implements the logic, so no client can get it wrong.
The server publishes its API shape, and every frontend generates its types from that same definition.
If the server changes a field, the frontends fail to compile until they are updated. The problem is caught by the build, not by a user.
Mobile styling and web styling are genuinely different underneath, so we do not force them together.
Trying to share the wrong thing causes more pain than duplicating it. Share logic, data shapes, and rendering rules. Keep platform-specific styling separate.
A small team can maintain a big surface area without going slowly insane.
Discipline fails on a busy week. A build that refuses to compile does not.
We use one server API, one canonical repo for shared rendering files, and types generated from the server's API definition. Consistency is enforced by the build, not by memory.
We share logic, data shapes, and rendering rules, and keep platform-specific styling separate. Web and mobile styling differ underneath, so forcing them together causes more pain than duplicating them.
The server publishes its API definition, and each frontend generates its types from it. If a field changes, the frontends fail to compile until updated, so mismatches are caught at build time instead of by users.
The server cleans the content and derives plain text, table of contents, and reading time once. Every surface gets the same result, so no client can process it differently.
Platform-specific styling. The two are built differently underneath, and sharing it usually costs more than it saves
Yes, if shared pieces have one source of truth and the server owns the hard logic. That keeps the workload manageable as surfaces grow.
Yes. We build web platforms, dashboards, and mobile apps on one shared API so they stay consistent as they grow. Get in touch to discuss your project.