Technology
Deliberately conventional choices. Anything we build has to be maintainable by whoever comes next, which rules out clever tools with small communities.
How we choose
Three tests: can you hire for it, is it still going to be maintained in five years, and does it have documentation good enough that a new developer can get productive without us?
Novel frameworks fail at least one of those almost every time. The interesting part of your project should be your product, not the stack it runs on.
- Widely adopted, easy to hire for
- Strong documentation and long-term support
- Runs in your cloud account, not ours
- No proprietary lock-in to our tooling
How the stack is chosen
Nothing here is picked because it is new. Each choice has to survive the same three questions: can your team hire for it, will it still be maintained in three years, and how expensive is it to leave. A tool that fails the third question is a liability regardless of how well it demos.
Where your team already runs something reasonable, we use that instead. Introducing a second language or a second cloud into a small team is a cost that outlasts the project, and it is rarely worth paying for a marginal technical gain.
What stays out
Orchestration frameworks that wrap a model API in four layers of abstraction, when the API is twenty lines of code. Vector databases where Postgres with an index would do. Kubernetes for an application serving a few hundred users a day.
Every abstraction has to earn its place, because each one is something the person inheriting the codebase has to learn before they can change anything.
The stack
Conventional tools, chosen so somebody else can maintain them.
Python
AI, data pipelines, automation and backend services.
More on pythonReact & Next.js
Interfaces, dashboards and AI product front ends.
More on react & next.jsNode.js
APIs, streaming backends and integration services.
More on node.jsVector Databases
The retrieval layer behind search and RAG.
More on vector databasesCloud & Deployment
Infrastructure you own, deployments that are boring.
More on cloud & deploymentFrequently asked questions
Can you work in a different stack?
Within reason, yes — if your team already runs something else, fitting in is usually better than introducing a second stack for them to maintain.
Tell us what you are building.
Send a short description of the problem and we will reply within one business day with an honest view of scope, cost and whether we are the right person for it.
Or email directly: contact@hire-ai-dev.com