Our technology stack, and why your next engineer already knows it.
Every system we build runs on the same short list of technologies. All of them are years old, widely used and documented everywhere. When the repository is handed over, the engineers you hire next can read it without us in the room.
If a project you have already started has stalled, we take those over as well. See software project rescue.
What we build on.
This is the whole list, and it is short on purpose. The framework, the language and the database are held constant from one project to the next. Where the system runs is not, because all of it ships in containers.
Vue.js
The front end
Every screen your people work in is built in Vue. It is widely used and well documented, so the pool of engineers who can maintain it is large rather than specialist.
Spring Boot, in Kotlin or Java
The back end
Business rules, permissions, reporting, and the connections into whatever else you already run. Spring Boot is long established in business systems, and any Java team will recognize it on sight. We write it in Kotlin or in Java. Both are current, both run on the same platform, and an engineer who knows one can read the other.
PostgreSQL
The database
Your data sits in an open database that a large number of engineers already know, not in a format only one vendor can read. It runs on your own infrastructure if that is where you want it.
Docker
How it is packaged, and where it runs
The application is packaged into containers, so the version that was tested is the version that runs. It is also what keeps the hosting portable: containers run on providers that support them, and DigitalOcean is where we run systems today.
Twilio
Text messages
When a system has to text somebody that a job is ready, or that a driver is on the way, it goes through Twilio. Messaging is a solved problem with an established provider behind it, so we do not write that part ourselves. The account can be in your name.
Mailgun
The same decision for email: notifications, documents and anything the system sends in a batch go through Mailgun rather than through something we built. The account can be in your name here as well.
Nothing on that list was picked because it was new, and none of it needs a specialist you cannot hire. Where the system runs is your call as well: keep it on your own infrastructure, or leave it with us.
If the build has already stalled.
We take over projects that somebody else started. It begins with a recovery assessment, where we read the code you have and tell you what is worth keeping, and it ends with a fixed price and a date to reach a working product.
Why the stack does not change every year.
New frameworks arrive constantly, and few of them last long enough to be a safe place to put a system your operations depend on. We would rather be late to a technology than early to one that gets abandoned. So the stack has two layers, and we treat them differently on purpose.
Fixed: the framework, the language, the database
Vue.js on the front end, Spring Boot on the back end in Kotlin or Java, PostgreSQL underneath. That does not change from one project to the next, and it does not change because something new was announced. It is the part that decides whether the engineer you hire in two years can open the repository and get to work.
Flexible: where it runs
The application is packaged in Docker containers, so it is not welded to one place. DigitalOcean is where we run systems today, and containers run on providers that support them. Where your system lives stays a decision you can take again later, rather than one you made once by accident.
The layer that decides who can maintain your system stays still. The layer that decides where it runs stays movable. Four reasons that is the right way round:
You can hire for it
The fixed half of the stack has a deep pool of engineers already working in it. If you bring maintenance in house later, you are hiring for common skills rather than searching for the one person who understands our choices.
The hard parts are already solved
Years of production use means somebody else hit the difficult cases first and wrote them down. Your project is not where a new tool finds out what it is bad at.
The stack is not the risky part
Projects fail on the parts nobody has done before. That should never be the technology underneath. We keep that surface small so the risk sits where the real work is, in your own rules and your own data.
We do not experiment on your system
If something is new to us, your build is not where it gets tried. New technology has to earn its place on our own time before it goes near work somebody is depending on.
A small first version and a scale-ready system, on the same stack.
The first version of a system is usually small. A few screens, one team, one location. The question worth asking at the start is what happens when it is none of those things.
Start with a first version that is real
A first version does not need everything that ended up on the wish list. We build the part that carries the most weight, put it in front of the people who do the work, and add from there. It is production software from the first release, not a prototype somebody has to throw away later.
Scale-ready, on the same foundation
More users, more data, more connections into other systems: the stack that carried the first version carries that too. Growing the system means adding to what is there rather than starting again, so the decision to expand is a business decision and not a rebuild.
One note on how the work gets done. Your software is built in TalkIDE, the environment we built and run our own AI development teams in. TalkIDE is the tool the software is built in, not a platform it runs on, so what you end up with is ordinary source code on the stack above, in a repository you control. Nothing you get from us depends on you keeping TalkIDE, or on you keeping us.
Tell us what it has to do.
Book a 30-minute call. We will tell you what we would build it on, and if there is code already, what we make of it.