A 10-Minute Decision That Almost Cost a Project
Some time ago, a client asked me for help to unblock the development of a mobile application. The issue was data persistence: the app had to allow inspections to be collected in areas without network coverage, which meant the data had to be stored temporarily on the device. Initially, a relational database was chosen—a decision that seemed technically sound.
The problem: the data was structurally closer to documents than to rigid tables. This, combined with constant changes in requirements, turned the architecture into a nightmare. Every time a field was added or a form was modified, the team had to perform complex database migrations and manual transformations that consumed a lot of time and generated constant errors.
The solution I proposed: store the data in JSON files—more than sufficient to hold the information temporarily until it was time to transmit it.
Code Is a Liability, the Product Is the Asset
A mobile developer with a CTO mindset doesn’t just write code that works; they write code that builds a company. The difference lies in moving from “How do I implement this?” to “Why are we doing this, and at what cost?”
This is how a strategic profile thinks:
- Code as debt: They understand that every line of code written is something that will need to be maintained and paid for in the future. Knowing when not to code is just as valuable as knowing how to do it.
- “Boring” but solid technology: Even if they’re passionate about innovation, they prefer mature technologies. Why? Because it’s easier to find talent, they have fewer unexpected bugs, and they ensure the app will still be alive in two years.
- An “App Store” mindset: Unlike the web, a mobile app isn’t updated instantly. A production bug can take days to fix due to Apple or Google review times and user update cycles. Thinking like a CTO means much stricter risk management before each release and valuing techniques (e.g., feature flags) that allow app behavior to change without publishing a new version.
- Balancing speed and debt: They know that shortcuts can be taken in an MVP (Minimum Viable Product) to validate the market, but they can clearly identify when it’s time to “clean the house” so the app doesn’t collapse under its own weight months later.
Common Mistakes That Kill Startups and SMEs
- Ignoring critical technical uncertainty: If your value depends on a technical innovation or demanding performance requirements, don’t build the entire app at once. Create a three-day proof of concept. If the technology doesn’t deliver, you won’t have lost three months.
- Waiting too long to validate the business model: Especially critical if your app proposes a highly innovative feature that the market may never truly value.
- Over-engineering: Software architectures and design patterns are powerful tools that should be used judiciously. Ignoring them is just as harmful as applying them blindly.
How to Spot (or Train) This Mindset
Developing this vision doesn’t happen overnight; it’s a shift in focus. If you want to know whether your team has this “chip,” or you want to help them develop it, look for these signals:
| Traditional approach | “Thinking like a CTO” approach |
|---|---|
| “We need to refactor this module.” | “If we invest 2 days cleaning up this module, the next features will ship 30% faster.” |
| “Let’s use the latest library that came out yesterday.” | “Does this library have a community? Will it be supported in 2 years? Is it secure?” |
| “I’ve finished the task according to the ticket.” | “I’ve noticed this feature doesn’t help this month’s user retention goal—are we sure we want it this way?” |
Fall in love with the problem, not the solution. If a user’s problem can be solved with a simple screen instead of a complex 3D animation—and that saves 40 hours of budget—the “Developer-CTO” will always choose the savings and reinvest them in what actually generates revenue.