The stack we build with, and the one we teach
These are the same lists. We do not keep a longer capability deck for sales and a shorter one for delivery. If a technology is here, someone at Prakmas has shipped with it and can explain the trade-offs behind choosing it.
6
Capability domains
50
Technologies listed here
3
Training tracks
2
Delivery locations
A long technology list is not a capability
Any firm can print a logo grid of frameworks. What matters is which ones the team reaches for under pressure, and whether anyone can explain why.
We keep the stack deliberately narrow. Six domains, and within each one a set of tools we use often enough to know their failure modes rather than their marketing pages. That is a constraint, and it costs us work. We turn down projects that need a specialism we do not have in-house.
It also means the engineer who scopes your project has debugged the thing they are recommending. Technology selection at Prakmas is not a matter of what is current; it is a matter of what we can still support in eighteen months, and what your own team can maintain once we hand it over.
Six domains, and what we actually do in each
Grouped the way the work is grouped. The lists are complete rather than illustrative. Nothing is held back, and nothing is padded.
Interfaces that survive contact with real content
Most frontend problems are not framework problems. They are state that lives in the wrong place, a component tree that mirrors the design file instead of the data, and a bundle nobody has looked at since launch. We build server-rendered by default and reach for client state only where interaction genuinely requires it.
- React.js
- Next.js
- TypeScript
- Tailwind CSS
- Vue.js
- Angular
- Redux
- HTML5 / CSS3
How a technology earns its place
Selection is where most long-term cost is set, and it happens in the first fortnight of a project when nobody is watching. These are the four traps we design against.
A stack was chosen because it was current, and now nobody on the team can maintain it.
We pick from the set we build and teach with daily, and we say so when a request falls outside it.
The people supporting your system are the people who know it.
Every new requirement adds a service, and the architecture is now the integration.
New infrastructure has to earn its place against the boring option that already works.
Fewer moving parts to run, monitor, and hand over.
AI has been added to the product without a clear job for it to do.
We start from the task being automated and check whether a model is the cheapest way to do it.
A feature you can explain to a customer, not a demo that ages badly.
The codebase works but no new engineer can be productive in it.
Typed interfaces, tests at the boundaries, and a README that describes how to run the thing.
Onboarding measured in days rather than weeks.
We teach the same stack we ship
Full Stack, Cloud, and DevOps tracks, with free internships. It is not a separate business. It runs on the same engineers and the same tooling, and each side sharpens the other.
Teaching forces precision
You discover the parts of a deploy pipeline you only half understand the first time you have to explain them to someone who has never seen one. Preparing training material is the cheapest audit of our own knowledge we have found.
Internships are how we hire
The free internship route means we work alongside engineers before offering them a role, rather than judging them on a ninety-minute interview. Trainees are not placed on client work unsupervised.
The curriculum tracks the client work
When a tool proves itself on a project, it enters the training material. When something stops earning its place in our builds, it comes out. The syllabus is downstream of what we ship.
Positions we have taken on this stack
Technology choices are easier to judge from the arguments a firm is willing to make in public than from the list it publishes.
All insightsWhat we tell clients before they add an LLM to their product
Most requests we get for AI features describe a solution rather than a problem. The useful first conversation is about what happens when the model is confidently wrong.
What running a training programme taught us about hiring engineers
We run free internships alongside client delivery. Watching people learn over weeks made our own interview process look considerably less useful than it did before.
Most cloud migrations do not need a rewrite
The instinct to re-architect everything on the way to cloud is how a migration becomes a multi-year programme that stalls. Move it first. Then fix what the bill points at.
Questions about the stack
The technology questions we are asked most often, answered without the hedging.
Sometimes, and we will tell you when that is the case. Picking up an unfamiliar framework on a client deadline is a cost someone pays, and it should not be you without knowing. Where a project genuinely needs a stack we do not run, a referral is the more honest answer.
Mostly by what your team can maintain after we leave. If you already have in-house capability in one of them, that usually settles it. On a clean slate we default to React with Next.js, because it is the stack we build and teach with most and therefore the one we can support the deepest.
We build with them where there is a defined job: retrieval-augmented search, classification, drafting. We also write publicly about the cases where adding a model is the wrong call, which is a fair test of whether a firm has used one in anger.
The Full Stack, Cloud, and DevOps tracks cover the same stack listed on this page. Preparing material forces precision. You find the gaps in your own understanding the first time you have to teach a deploy pipeline to someone who has never seen one. The free internship route is also how we meet engineers before hiring them.
Yes, and it is often the right call. A slow or awkward system is usually a handful of specific problems rather than a case for a rewrite. We would start with a read of the code and a written assessment before recommending anything expensive.
You do. Infrastructure is defined in code in your repository, environments are reproducible, and handover includes a runbook covering deploy steps and credentials. If a different team continues the work, they should be able to.
Tell us what the system has to do
We will tell you what it takes to build, which parts of this stack it needs, and where you could get away with less.