Learning platforms built by people who run one
We run training programmes ourselves, in Full Stack, Cloud, and DevOps, with free internships. So the problems in education software are ones we hit on a Tuesday rather than ones we have read about: learners on weak connections, mentors buried in submissions, and a cohort spreadsheet nobody fully trusts.
What makes education software hard
Before anything about us. These are the constraints that shape every education build, and the reason generic delivery comes unstuck here.
Week two is where you lose people
Sign-up is easy to design for. The session after the initial enthusiasm fades is where completion is actually decided, and most of that drop-off is a product problem rather than a motivation one.
The device they have, not the one you tested on
A large share of learners are on mid-range Android phones and mobile data. Video that stalls does not degrade the lesson. It ends it.
Assessment has to be fair in both directions
Evaluation must be hard to game without treating honest learners as suspects, and it has to stay workable for the person doing the marking.
Education capabilities
Four areas we take on in this sector. Each one is work we do rather than a category we list.
Platforms people open again on day nine
Onboarding is the easy part to design. The hard part is the session after motivation has gone, when a learner has fifteen minutes and needs to land precisely where they left off.
- Structured course and module delivery
- Progress tracking with real resumption
- Mobile-first learner interfaces
- Access to content already downloaded
- Notifications that are useful rather than constant
- Certificates and completion records
Where these projects actually go wrong
The recurring failure patterns in this sector, what we do differently, and what that changes. You will not find a claimed figure here. Those belong to engagements we can name, and we do not name what we cannot evidence.
Learners enrol, stop appearing in week two, and nobody can say which module lost them.
Progress tracking that resumes precisely, plus playback and completion analytics that name the specific point where people leave.
Drop-off becomes a located product problem instead of a general worry about motivation.
Course video stalls on the connections and devices most learners actually use.
Adaptive bitrate streaming with defaults set from available bandwidth, playback that resumes, and transcripts as a second route through the same material.
A weak connection costs picture quality rather than the lesson.
Submissions get reviewed by hand out of an inbox, so feedback lands after the learner has already moved on.
Reviewer queues with rubric grading and threaded feedback, designed around the mentor as a primary user rather than a recipient of exports.
Feedback speed stops being set by the tooling.
Administrators run cohorts from a spreadsheet that disagrees with the platform, and reconcile the two by hand before every report.
Cohort, enrolment, and scheduling built into the platform, with exports for the institutional reporting that genuinely has to live elsewhere.
One record of who is enrolled in what, and an export for where a spreadsheet is genuinely required.
Commitments, not promises
How we build for education clients. Each one is checkable in the work itself rather than a claim about results you cannot see.
We run one of these
Prakmas delivers Full Stack, Cloud, and DevOps training with free internships. The operational problems in this sector are ones we hit ourselves.
Built for the connection they have
Interfaces are tested on throttled connections and mid-range devices before anyone calls them finished.
The mentor is a user too
Reviewer tooling gets designed alongside the learner experience, because feedback speed is set by whichever of the two is worse.
Three ways this usually starts
Prices are not listed because they depend on scope. We quote a range after discovery, along with the specific things that would move it toward each end.
Discovery
Best before you commit
A short paid engagement that ends with a scoped plan you own, whether or not we build it. If the honest answer is that you should not build software at all, that is what the document will say.
- Requirements and constraints captured
- Technical and integration assessment
- Architecture and approach outline
- An estimate as a range, with its drivers
- Risks named rather than implied
Project build
Best for a defined outcome
A scoped build with an agreed deliverable, run in short cycles with something you can review at the end of each one. Suited to work where the shape of the outcome is already clear.
- Fixed scope with a change process
- Something reviewable every cycle
- Design, build, test, and deploy
- Documentation and runbooks
- Handover to your team
Dedicated team
Best for an ongoing roadmap
A small team working continuously against your priorities, with capacity you can plan around. Suited to products that keep changing rather than projects that finish.
- Named engineers, consistent over time
- Priorities you set each cycle
- Direct access to the people building
- Shared repository and tooling
- Exit on notice, with no lock-in
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.
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.
How 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.
Education: what buyers ask us
Including the ones where the answer is no. A limit stated up front is worth more than a capability claimed now and found out later.
Because we run one. Prakmas delivers Full Stack, Cloud, and DevOps training with free internships, so enrolment, cohort scheduling, mentor load, and learners on weak connections are problems we hit ourselves. That is the claim, and it is a narrow one. We know the delivery problems well. We are not a curriculum design firm.
If an off-the-shelf LMS covers your delivery model, use it and spend the money elsewhere. Custom is justified when the platform is fighting the model: unusual cohort structures, assessment workflows it will not represent, deep integration with student records, or a learner experience that is genuinely part of what you sell. We will tell you which case you are in during scoping.
With proportionate measures rather than surveillance. Attempt history, question pooling and randomisation, time bounds, and submission fingerprints raise the cost of gaming an assessment considerably. We do not build webcam proctoring or keystroke monitoring. The false positives land on honest learners, and the same effort spent designing an assessment that is harder to game gets you further.
That is a design constraint from the first week, not a late consideration. A meaningful share of learners in our own programmes are on mid-range Android devices and mobile data. We test on throttled connections, keep pages light, make video degrade rather than stall, and treat access to already-downloaded content as a normal requirement.
Yes, where the system exposes an API or a scheduled export. The question we settle early is which system owns each record: enrolment, grades, attendance. Most integration pain in this sector comes from two systems both believing they are authoritative for the same field, and that is an architecture decision rather than a bug to fix later.
No. We build the platform that delivers it. Curriculum design and content production are separate disciplines, and we work alongside your subject-matter people rather than substituting for them. Where the subject is our own ground, meaning Full Stack, Cloud, or DevOps, that is a training conversation rather than a software one.
Industries we work in
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
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
Let's talk about your education project
A scoping conversation costs nothing. You leave with a clear view of the approach, a budget range, and the main risks named out loud, including an honest no if we are not the right firm for this.