Custom applications
Applications built for a specific problem, with the logic kept apart from the interface so they can be maintained and grown without fear.
What usually goes wrong
Many applications work on day one and become impossible to touch six months later, because the logic is mixed with the screens and every change breaks something else. That's not a technology problem, it's how it was put together.
How I do it
I keep what the application does apart from how it looks. I've applied it to everything I've built: at Savia, in DevConsole and in Kairos, where the Flutter app knows nothing about the database and the FastAPI server knows nothing about the interface.
- -Logic apart from the interfaceIf the screen changes tomorrow, the logic isn't touched. And the other way round.
- -Built to handle dataAt Savia I built a React 19 app that handled more than 1000 records with instant search and filters.
- -Whatever technology fitsI've worked with React, Vue, Flutter, Laravel and FastAPI. I use what makes sense for the problem, not what's trendy.
- -Easy to maintainCode someone else can read without having to ask me.
How I'd do it
Understand what it has to do
Who will use it, what for and what data it handles. Whatever isn't needed in the first version waits.
- ›Users and use cases
- ›Data
- ›First version
Lay the foundations
Separate the layers, define the data and the API before filling screens.
- ›Architecture
- ›Data model
- ›API
Build and deploy
Move forward in reviewable parts, with tests where they help, and take it to production.
- ›Small parts
- ›Tests
- ›Docker deployment
What it should include
- ✓Logic apart from the interface
- ✓Data model designed to grow
- ✓Documented API
- ✓Tests where it matters
- ✓Reproducible deployment
- ✓Readable code