Eleven builds we can show you
Commerce, banking, healthcare, learning platforms, and the two training programmes we run. Each entry says what the software does and what it was built with. No client logos, because most of this work sits under an agreement that keeps the name off a public page.
A portfolio proves capability, not fit
You are not here to admire screenshots. You are working out two things: whether we have built something structurally like the thing you need, and whether the way we work would survive contact with your organisation.
The first question this page can answer. Eleven builds follow, across commerce, banking, healthcare, social, learning and franchise operations, plus the two training programmes we run. Every one lists the stack it was built on, so you can judge the engineering rather than the art direction.
The second question a page cannot answer, and pretending otherwise would only waste your afternoon. Where a client has not agreed to be named, the work is described by what it does rather than who it was for. You will find no invented metrics here, no satisfaction scores and no awards, because a number with nothing behind it is worth less than nothing to a buyer who checks. What we can set out precisely is the method, and that is the section after the work.
11
Projects on this page
5
Kinds of work
27
Technologies used
2
Delivery locations
The work, and what each piece is made of
Eleven projects, in no ranked order. Category and year come from the engagement itself. The technologies listed against each one are the technologies it was actually built with.
E-Commerce Platform
A storefront, catalogue and checkout with live inventory, so stock counts move as orders land rather than on an overnight batch.
Mobile Banking App
A banking app with biometric sign-in, account-to-account transfers, and a balance and transaction view that updates as payments clear.
Corporate Brand Identity
A full identity rebuild: logo system, type and colour rules, a written guideline set, and the print and digital collateral redrawn to match.
SaaS Dashboard
A reporting dashboard with live charts, filters people can save, and custom report builds for teams who need their own cut of the data.
Social Media Platform
A community platform with profiles, live streaming, creator payouts, and a recommendation feed built on what people actually watch.
Healthcare Portal
A patient management portal built against HIPAA requirements: medical records, appointment scheduling, and video consultations in one place.
Fitness Tracking App
A training app that builds workout plans from past sessions, logs nutrition alongside them, and charts progress week to week.
Food Franchise Platform
Franchise operations and delivery in one system: many outlets, separate menus and pricing per outlet, and order tracking from kitchen to door.
Education Platform
A learning platform with live classes, course and cohort management, progress tracking per student, and certificates issued at completion.
Full Stack Training
Our MERN programme, taught in cohorts and built around projects that ship, mentored by the engineers who do this work here day to day.
Cloud & DevOps Academy
Certification training across AWS, Azure and GCP, taught through lab work and real deployments and aimed at the vendor exams themselves.
What you get from us that is not the software itself
We do not publish success rates or satisfaction scores. What we can describe precisely is the method, and the method is the part that decides whether a project ends well or ends late.
The requirement exists as a conversation, and every estimate against it is guesswork.
A written scope before a quote, listing what the software does and what it explicitly does not.
You can tell whether a change is in scope without arguing about it later.
Progress is invisible until a milestone demo, by which point the misunderstanding is expensive.
A deployed environment from the first week, on a repository you can read at any time.
Nothing at handover is the first time you have seen it.
The build works, but only on the machine of the person who wrote it.
Infrastructure defined in code, environments reproducible, deployment scripted rather than remembered.
The system can be rebuilt from the repository without us in the room.
The team that built it leaves, and the knowledge goes with them.
A written runbook covering environments, credentials, deploy steps, and the decisions that are hard to reverse.
A different team can pick the project up, including yours.
The practices these projects were built out of
Nine services, grouped the way we actually staff them. Every project above draws on more than one, which is why design and engineering sit in the same team instead of passing work across a boundary.
All servicesProduct work
Most of the projects above started here: a web application, a mobile app, or an interface layer over a system already in use.
Run it in the open
The part of each build a screenshot cannot show. Environments, release process, and machine learning where it earns its place.
Around the build
The two training programmes above sit here, next to identity work and the franchise tooling we run as a standing practice.
Sectors we build for
Domain context changes what correct looks like. An appointment system and a claims workflow fail in different ways, and they need to be designed against different constraints. These pages set out those constraints sector by sector, and what we build to meet them.
All industries2.4M
99.9
318
12ms
Runbook
Healthcare
Patient portals and clinical tooling, built to be audited
Fintech & Banking
Payment flows and the ops tooling behind them
E-commerce & Retail
Storefronts that load, checkouts that finish
Education
Learning platforms built by people who run one
Logistics
Tracking and field apps for teams without a signal
Real Estate
Listing platforms that are fast and findable
Manufacturing
Production visibility for the floor and the office
Insurance
Quote and claims flows that survive an interruption
How we think about the work above
Three pieces that bear directly on how the projects above were scoped, built and handed over.
All insightsHow we scope a project, and why we sometimes say no
A scoping call that ends in an honest no is worth more to both sides than an engagement that starts on a misunderstanding.
Page weight is a business metric, not a technical one
We cut our own site from 81MB of assets to 21MB and nothing on screen got worse. Most heavy sites are not heavy by decision. They are heavy because nobody owned the number.
Server rendering, and why your SEO still depends on it
Search engines execute JavaScript now. That has not made client-only rendering safe for anything whose discovery matters to the business.
What people ask after looking at somebody else's work
These are the questions that actually follow a portfolio, including the two we answer with a qualified yes rather than a flat one.
Yes, on a call. Some of the work sits under an agreement that keeps it off a public page, so what is published here is the part we are free to publish. On a scoping call we can walk through more of it on screen, including builds closer to yours than anything above.
We ask that client first, every time. We do not keep a list of references on the site and we do not put anyone forward without their agreement. Where a client says yes, we make the introduction and then stay out of the thread, so you can ask whatever you want to ask. If we cannot arrange one for the kind of work you are doing, we will tell you that rather than offer something vaguer instead.
Usually not. The work above covers commerce, banking, healthcare, learning and franchise operations, and it covers that range because the underlying problems repeat: a data model, a set of roles and permissions, integrations with systems you do not control, and an interface people use while under time pressure. Sector experience matters less than whether we can describe your problem back to you accurately. If we cannot, that is the point to stop, and we will say so.
You do, from the first commit. Work goes into a repository under your ownership where you want it there, design files are handed over in their source format rather than as flat exports, and infrastructure is defined in code so it can move with you. We do not hold environments or credentials to make leaving difficult.
That is a separate conversation with a separate agreement, and we would rather have it out loud than assume it. Some clients take the full handover with a runbook and carry on in house. Others keep us on for maintenance and small releases. The handover pack is the same either way, so you can decide after launch instead of committing before it.
Yes. Prakmas is a small firm across Hyderabad and Union City, and the engineers who scope a project are the ones who build it. There is no separate delivery team you get handed to once the contract is signed. The trade-off is real: we turn work away when we cannot staff it properly, which is better for you than a team assembled against your deadline.
Failure cases
Describe the problem and we will tell you what it takes
Including when the honest answer is that you need less than you think, or that we are not the right firm for it. Both happen often enough to be worth saying up front.