Inside the STEMLink and Zone24x7 Externship

What Problem Were the Students Asked to Solve?

A centralised licensing system solves the problem of managing product access, subscriptions, seats, pricing and entitlements independently across multiple software products. Instead of each product maintaining separate licensing rules, a shared system can centralise entitlement management, automate subscription processes and provide a consistent customer experience.

Now watch what happens on an ordinary Tuesday.

A customer upgrades their plan, so a feature needs to switch on. Another customer stops paying, so their access needs to switch off. A third removes an employee from their subscription, so that person's seat needs to be revoked. Somewhere else, the sales team wants to change the price of a tier.

Each of these is small. None of them should be difficult. But when every product manages its own rules independently, all of them are.

The pricing logic lives inside the application code, so changing a price means changing software, which means a developer, a code review, and a release. Access has to be granted by hand after a purchase, so customers wait for an email instead of getting what they paid for immediately. Nobody can see which features are actually being used, or whether the software is being opened at all. And when a customer stops paying, there is no central mechanism to turn anything off, so features quietly stay on.

Then comes the part that costs the most: the arguments. Different products handle subscriptions differently, so the same customer has a different experience depending on which product they bought. Finance cannot reconcile what was sold with what was delivered. Support absorbs the difference.

This is the problem Zone24x7 handed to three STEMLink learners. Not "build us an app." Something closer to: here is a structural weakness that sits behind a great many software businesses, go work out what should exist instead.

Who Took on the Challenge?

Three STEMLink learners worked together to design and build the licensing system for Zone24x7. Rather than working in isolated roles, the team shared responsibility across architecture, security, development and quality, giving them experience similar to working on a real product team.

Three learners took it on, working as a single team rather than dividing into isolated lanes.

That matters more than it sounds. On a team of three building an entire system, nobody gets to be only a backend engineer or only a designer. Everyone ends up touching the architecture, everyone has to understand the security model, and someone has to own quality without a dedicated QA function existing. The boundaries between roles turn out to be far more porous than job titles suggest, which is a fairly accurate preview of how small product teams actually work.

They were placed with Zone24x7 through STEMLink's externship programme. Zone24x7 is a global technology and research organisation headquartered in the United States with a major technology talent hub in Sri Lanka. It works across software engineering, AI and machine learning, data science, embedded systems, IoT, DevOps, and enterprise technology solutions, with more than two decades of building technology for businesses across multiple industries.

That depth is what made the brief possible. A company without real products and real licensing pain could not have posed this problem convincingly.

What Did the Team Need to Build?

The licensing system needed to be product-agnostic, centralised, automated, self-service and adaptable. It had to support different products and pricing models while automating subscription processes and allowing customers to manage their own users and seats.

The team did not start by writing code. They started by working out what the system had to be.

The first decision was the most consequential one: the system had to be product-agnostic. It could not be built for one product and adapted later. It had to serve any product in the portfolio, present and future, without knowing anything specific about them. That single constraint ruled out a great many convenient shortcuts.

From there, four commitments emerged.

Centralise. Pull the licensing logic out of individual products and put it into one secure shared server.

Automate. Let the system handle renewal reminders, credit card processing, and invoice issuing without a person in the loop.

Empower. Give customers a self-service portal to manage their own users and seats, so support and finance stop doing it for them.

Adapt. Make it possible to launch a new product or change a pricing tier in one place, without rewriting software.

Then came the harder question, and the one the team correctly identified as mission critical before anything else: how does a product actually talk to this thing?

Everything depends on that conversation. If it is slow, every feature check in every product becomes slow. If it is fragile, products break when the network hiccups. If it is insecure, the entire licensing system is decorative, because anyone who can forge a response can grant themselves anything.

How Did the Students Design the Solution?

The students designed the solution around a digital passport model. Products request a user's entitlements from a central licensing server, which returns a signed token. The product then checks the token locally for fast access decisions, while a periodic heartbeat keeps entitlement information up to date.

The answer they arrived at is a digital passport.

When a product starts up, it asks the licensing server what a given user is entitled to. The server works it out and returns a signed token containing the answer. The product holds that token and reads from it locally.

This solves the speed problem completely. When a user clicks Export PDF, the product does not ask the server whether that is allowed. It checks the token it already holds. A network request becomes a lookup in memory, and the licensing layer effectively disappears from the user's experience.

But a token that never changes would quickly start lying. Customers upgrade. Seats get revoked. Subscriptions lapse. So the design adds a heartbeat: the product periodically contacts the server for a fresh token, with a default interval of fifteen minutes.

There is a detail in the heartbeat worth pausing on. The refresh timing carries a random variation, so that a fleet of clients does not all wake up and call the server in the same instant. Without that jitter, every deployment creates a synchronised traffic spike against itself. It is a small piece of engineering that only matters at scale, and only occurs to people thinking about scale.

The resulting balance is deliberate: local checks for speed, periodic contact for freshness. The system does not have to choose between performance and control.

The wider architecture followed from there. A central server holding the subscription engine, the product registry, and the audit log. An entitlement API that products talk to. An admin dashboard for internal staff and finance. A customer portal for self-service. A database behind all of it, with a cache in front to keep responses fast.

How Do You Turn an Idea Into a Working Product?

The system was built around a central server, entitlement API, admin dashboard, customer portal and database with caching. It included product and plan management, subscription resolution, seat management, automated billing workflows, authentication and audit capabilities.

The build turned that design into a working system.

On the server side, that meant a product registry where a new product is defined along with its feature keys and default values, a plan and add-on system where tiers and prices and grants are configured, and a resolution engine that combines them. The resolution order is specific: defaults first, then the base plan, then any add-ons, then a check on whether the subscription is currently active, in grace, or expired. Only then is the answer signed and returned.

On the client side, that meant a set of components living inside each product: something to hold the credentials, something to schedule the heartbeat, something to store the token, something to verify its signature, and something to react when the server says access has been withdrawn.

Around the core, the team worked through everything a licensing system actually needs to be usable in a business. Customer and seat management. License keys generated automatically for assigned users. Seat limits enforced so nobody can over-allocate. Subscription states moving between active, grace, and expired on their own. Automated renewal reminders. Invoices generated and emailed. Card payments with webhook handling and follow-up when a payment fails. Manual bank transfer confirmation for customers who pay that way. A signup flow. Email verification. Welcome emails. An admin dashboard with role-based access and the ability to override a subscription state, with the override recorded.

That work was organised into forty backlog items across ten areas and four sprints. Foundations first, then the entitlement engine, then the money and customer flows, then admin tooling.

The sequencing is the interesting part. Payments and invoicing, which are the features a business person would name first, came third. The team built the thing everything else depends on before building the things everyone can see.

What Happens When Things Go Wrong?

Four problems in this system are genuinely hard, and how a team handles them separates a prototype from something you would run.

Making revocation instant when the design is built on caching. The entire performance model rests on products holding a token and not asking the server. But that is exactly what makes revoking someone difficult, because the product is deliberately not checking. The team accepted a bounded delay of one heartbeat cycle and made it explicit rather than pretending it did not exist. The seat is invalidated on the server immediately, and the client discovers it on its next check.

Telling an outage apart from a revocation. A product cannot stop working because the licensing server is briefly unreachable. So there is an offline grace mechanism: a previously valid token keeps working for up to twenty-four hours when the server cannot be reached, with the window configurable per product.

But that creates an obvious hole. If losing connection extends your access, then disconnecting deliberately becomes a way to keep a revoked seat alive.

The fix is that these two situations return different answers. An unreachable server returns nothing at all, and grace applies. A revoked seat returns a specific revocation response, and the client clears its token and locks out immediately, with no grace. To a naive client these look similar. Recognising that they mean opposite things, and building the client to treat them differently, is the single sharpest piece of thinking in the project.

Rotating security keys without breaking every client. Tokens are cryptographically signed, and signing keys should be replaced periodically. The problem is that clients verify signatures using a cached copy of the public key, so the moment you rotate, every client's cached key is wrong and every token fails verification.

The solution is self-healing. New and old keys are both published for a twenty-four hour overlap. When a client hits a signature it cannot verify, it treats that as a signal to re-fetch the key set, updates its cache, and retries. Verification succeeds and normal operation resumes. No restart, no coordinated deployment, no outage.

Keeping it fast under load. The first request for any given seat has to read from the database. Every subsequent one is served from a cache, which is invalidated the moment something meaningful changes: a seat revoked, a subscription state change, an add-on bought or removed, an admin override. The target was a response time that stays well under a tenth of a second at the ninety-ninth percentile, which is what keeps the heartbeat invisible.

What Was It Like to Solve a Real Industry Problem?

The difference between a classroom project and this one is that the requirements did not arrive fully formed.

Zone24x7 posed a business problem, not a specification. The team had to turn it into one. That meant asking questions, proposing an approach, and having the approach questioned back. It meant writing down assumptions explicitly, including uncomfortable ones like which products need instant revocation and which can tolerate a delay, because those assumptions changed the architecture.

It also meant designing for people who were not in the room. The system had to be usable by product teams who would integrate against it, by finance staff who would chase invoices, by support staff who would field the calls, and by customers managing their own seats. None of those groups would be there to explain what they meant. The design had to anticipate them.

And it meant accepting that the work would be reviewed by engineers with two decades of experience, who would notice if a shortcut had been taken.

What Did the Students Learn Along the Way?

The technical list is long: API design, authentication and authorisation, token-based security, signature verification and key rotation, caching strategies, rate limiting, subscription and billing lifecycles, and failure-mode design.

But the more durable lessons are the ones that do not fit on a skills list.

That trade-offs are the job. Speed against freshness. Availability against strictness. Every meaningful decision in this system gives something up, and the work is choosing which thing consciously rather than by accident.

That failure modes deserve as much design as success paths. The happy path in this system is simple. Nearly all the interesting engineering lives in what happens when the server is down, when a key rotates, when an admin revokes access, or when a payment fails.

That security is a design constraint, not a final step. Signed tokens, encrypted transport, hashed credentials, and immutable audit logging were part of the architecture from the start, because retrofitting any of them into a system that controls access would have meant rebuilding it.

That knowing what to build, in what order, is most of the work. Forty backlog items across four sprints is a set of decisions about sequence and priority, made before any of it was written.

And that writing things down changes the outcome. Assumptions that stay in someone's head cannot be challenged. Assumptions written on a slide get argued with, and the design gets better.

What was the Final Outcome?

LES was built and deployed. It is a working system, not a design exercise or a set of diagrams.

That distinction is what gives the rest of it weight. Every decision described above had to survive implementation. The heartbeat interval had to be a real number. The offline grace window had to be a real duration with real behaviour at both ends of it. The key rotation had to actually work, on real clients, without anyone redeploying anything.

The result is a single system that answers, for any product in the portfolio, what any given customer is entitled to use, and does so quickly enough that nobody notices it is there.

Why This Experience Matters?

The most valuable thing about an externship is not the line it adds to a CV.

It is the experience of working on a problem that has not been pre-shaped by a lecturer. In a classroom, the requirements are clear, the scope is fixed, and there is a known answer waiting at the end. In industry, none of that holds. The problem is ambiguous, the constraints compete, and the hardest part is often working out what you are actually being asked to build.

These three learners took a genuine structural problem, reasoned their way to a system that addresses it, made choices they had to justify, and shipped something a company now runs.

That is a fundamentally different education from following a tutorial to a known destination. And it is exactly what STEMLink's industry-focused learning is built around: not simply preparing learners to enter the technology industry, but giving them a chance to experience it before they do.