A small firm that stays close to the code
Prakmas Global Innovations Private Limited builds web, mobile, AI, and cloud software from Hyderabad and Union City, and runs Full Stack, Cloud, and DevOps training alongside it. We are not large, and the way we work depends on that.
The three phases
Prakmas
Close to
the code
prakmas.com
An engineering firm, and a training programme that feeds it
Two things sit under one company. We build software for clients, and we teach the same stack to people entering the industry. Both are run by the same engineers, which is the reason either works.
Prakmas Global Innovations Private Limited is a software company registered in India with a US office in Union City, California. The practice covers six areas: web, mobile, AI and machine learning, cloud, DevOps, and UI/UX. That list has not grown for the sake of a pitch deck. It is what the people here have actually shipped.
Because the firm is small, there is no account layer between you and the engineers. The person who scopes the work builds it. That costs us something obvious, since we cannot take on everything and we do turn work away. It buys one thing back: nothing gets lost being relayed between a salesperson, a project manager, and a developer who never spoke to you.
The training side runs Full Stack, Cloud, and DevOps tracks with free internships. It is not a side business bolted on for credibility. Teaching a technology properly is the fastest way to find the parts of it you only half understand, and the internship route is how we meet engineers before hiring them rather than after.
2
Offices in Hyderabad and Union City
6
Practice areas
3
Training tracks
Free
Internship programme
Five steps, and none of them are a surprise reveal
Most project failures we have seen were visible early and went unsaid. This sequence exists to make the awkward conversation happen in week two instead of week twelve.
Scope
We start by writing down what the software has to do and, just as importantly, what it does not. If the brief is thin, we say so before quoting rather than after. A scope we cannot describe in a page is a scope we do not understand yet.
Shape
Data model, integration points, and the two or three decisions that are expensive to reverse get settled first. Interface work follows the model, not the other way round. A screen designed before the data behind it is a screen that gets rebuilt.
Build in the open
Work lands in a repository you can see, on a deployed environment you can click through, from the first week. No milestone reveals. You should never be surprised by what we hand over, because you have been watching it arrive.
Review against the scope
Each increment is checked against what we agreed, not against what would be nice. Changes are welcome; they are logged as changes and re-estimated rather than absorbed silently into a slipping date.
Hand over properly
You get the repository, the infrastructure definitions, the environment variables, and a written runbook. If a different team picks the project up after us, they should be able to. That is the test we hold ourselves to.
Hyderabad and Union City
Two offices, each with a job. We are explicit about which one leads an engagement rather than implying a follow-the-sun operation we do not run.
Hyderabad, India
Engineering runs from here: build, review, deployment, and the training programme. If you are working with Prakmas, this is where the commits come from and where the day-to-day conversation happens.
Telangana 500047
Union City, California
The US registration and client contact point for North American work. It exists so that a buyer in the Bay Area has someone in their own time zone and legal jurisdiction to hold the contract with.
CA 94587, United States
The work we turn down
A firm that claims it can do everything is telling you something about its sales process, not its engineering. These are the three cases where we would rather lose the contract.
We say no to work we cannot staff properly
We are a small firm. If a project needs a specialism we do not have in-house, the honest answer is a referral, not a hire made against your deadline.
We say no to fixed scope on unclear problems
Where the requirement is still being discovered, a fixed-price contract just moves the risk around. We would rather run a short paid discovery and quote something real.
We say no to rewrites that nobody needs
A slow or awkward system is often a handful of fixable problems, not a rebuild. Rewrites are the most expensive advice a firm like ours can give, so we do not give it lightly.
What we think, written down
The clearest signal of how a firm works is what it argues for in public. These are positions taken from our own projects.
All insightsPage 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.
What 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.
Questions worth asking before you sign anything
These are the ones we get asked most, answered the way we would answer them on a call.
Prakmas is a small firm across Hyderabad and Union City. The engineers who scope your project are the engineers who build it. There is no separate delivery team you get handed to after signing. If a project needs more people than we can properly staff, we tell you that up front.
Engineering runs out of the Hyderabad development centre; the Union City, California office handles US-based client contact and covers the overlap hours. Which office leads an engagement depends on where you are and how much synchronous time the work needs.
We agree a fixed overlap window at the start of an engagement rather than promising round-the-clock availability we would not keep. Anything outside that window is handled asynchronously against a written record, which is a better default for most decisions anyway.
You do, from the first commit. Work goes into a repository under your ownership where you want that, and infrastructure is defined in code so it can be handed over intact. We do not hold environments or credentials hostage as a retention strategy.
Most start with a short scoping conversation, then a written scope with an estimate against it. From there the common shapes are a fixed-scope build, an ongoing team working in iterations, or a maintenance arrangement on an existing system. We will tell you which one fits your problem, including when it is the cheapest one.
That is a separate conversation with a separate agreement, and we would rather have it explicitly. Some clients take full handover with a runbook; others keep us on for maintenance and iteration. Neither is assumed by default.
We run Full Stack, Cloud, and DevOps training with free internships, and the two sides feed each other. Teaching a stack forces us to know it precisely, and the internship route is how we find engineers who already work the way we do. Trainees do not get put on client work unsupervised.
Email info@prakmas.com and describe the problem in your own words. It does not have to be a specification. The first useful reply we can give is usually about whether the problem is shaped the way you think it is, and that costs nothing.
Tell us the problem, not the specification
The most useful first reply we can give is usually about whether the problem is shaped the way you think it is. That conversation costs nothing.