Enterprise systems need enterprise standards

There is a particular discipline that comes from building inside an enterprise you do not own. You are not choosing the standard, you are meeting it, and you find out early that the interesting constraints are rarely the technical ones. They are the ones that come from the fact that this platform sits next to systems that already work, already carry load, and already have people accountable for them.

The Personal Shopper platform serves three user groups across two products, and it does so behind Takealot's own single sign-on, integrated into their existing systems, built to their enterprise-grade security standards. Every one of those phrases is a constraint before it is a feature, and taken together they decided most of the architecture before we wrote anything.

Identity you do not own

The first real decision was to put the shopper app behind Takealot single sign-on rather than minting a parallel identity of our own. That is the more constrained option and it is obviously the correct one, because the alternative means running a second source of truth about who someone is, and a second place for that truth to go stale, inside a company that already has a working answer.

What you accept in exchange is that session lifetime is not yours to tune. Sessions expire on someone else's schedule, tokens refresh on someone else's terms, and the failure modes you have to design for are the ones the identity layer produces rather than the ones you would have chosen. For a field application that matters more than it would for an internal tool: a shopper is standing in a shop, on a phone, on a connection that comes and goes, and an expiry that is merely inconvenient at a desk is a lost sale in a queue. So the app is built to treat an interrupted session as a normal event rather than an error state, and to lose nothing when one happens.

Integrating with someone else's identity is the more constrained choice, and it is the one that leaves you with a single answer to who this person is.

Sync is a correctness problem, not a plumbing one

Orders sync from Takealot hourly, and it is tempting to file that under plumbing. It is not plumbing, because of what those orders represent: commission. The numbers moving across that boundary are the numbers a shopper uses to work out what they have earned this month, and a platform that disagrees with the system of record about someone's income has not got a data problem, it has a trust problem, and trust is considerably harder to restore than a record.

That reframing changes the engineering. A sync you think of as plumbing gets built for the happy path and patched when it drifts. A sync you think of as a correctness guarantee gets built so that partial failure is visible rather than silent, so that replaying it is safe rather than duplicative, and so that the platform never presents a figure it cannot reconcile with the source. The interval itself is the least interesting part of the design.

The best product for a business layer is no product

Three user groups needed serving and only two got an interface. The shoppers got the app, the team running the network got the Community Manager dashboard, and the third group - the Takealot business itself - is served through direct integration into systems that already exist, with no dedicated interface at all.

That is an architectural decision rather than a scoping compromise, and it is the one I would defend hardest. Every interface you add is a surface that has to be secured, supported, kept current with the rest of the platform and staffed by someone whose actual job is something else. When the consumer of your data is a business function that already has tools, the honest answer is to integrate properly and build nothing, and the discipline is in resisting the instinct to give every stakeholder a screen so they can see that you built them something.

What makes two products a platform

The shopper app and the Community Manager dashboard share one authentication, one data infrastructure and one design system. None of that is visible from the outside, and it is the whole reason the two feel like one platform rather than two applications that happen to share a client.

The failure mode when you skip it is familiar to anyone who has inherited an estate: two products that were built a quarter apart, each with its own idea of who a user is, its own reporting, and its own component that renders a button. Every subsequent change then costs twice, and the second copy is always the one that gets forgotten. Doing this once, at the start, is the least glamorous work in the build and the reason the platform can still absorb features now without a rewrite.

The delivery surface follows the same logic. The shopper app is an installable progressive web app, which for a field user on a mid-range Android handset means no app store, no update cycle to chase and no install friction between hearing about the thing and using it. That is a distribution decision expressed as an architectural one, and for this audience it was not close.

Designing for a load you have not seen yet

The platform now carries more than 40,000 transactions a month across a network of 14,000+ shoppers, and growing. The word doing the work in that sentence is growing, because designing for the number you have is how you end up rebuilding at three times the number.

In practice that meant treating the integration boundary as the thing most likely to bend first, and being deliberate about what happens on the far side of it when volume climbs: what is queued rather than blocking, what degrades rather than fails, and what the platform still guarantees when a dependency is slow. Enterprise-grade is not a tier of hosting or a certificate on a wall. It is whether the system behaves predictably on the day something upstream does not, and whether the people who depend on it can tell the difference.