Client Work · October 2026

OCL Health: Building a Digital Health Platform for a Client

The story of building OCL Health for Okonkwo Chidinma Linda: a pharmacy and wellness platform designed to grow beyond a simple website.

Not every project in my GitHub is mine. OCL Health is an important example because it is a client build for Okonkwo Chidinma Linda and her team.

The goal is to build a serious digital foundation for a pharmacy, health, chemistry and wellness business rather than stopping at a brochure page. The repository describes a public website, health blog, product catalogue, customer accounts, shop, administration, developer documentation, API infrastructure and support surfaces as the wider direction.

The first production implementation uses Next.js, React and TypeScript and is connected to Vercel with Cloudflare DNS. That gives the project a practical foundation while leaving the deeper database, authentication, payments and API work for the backend phases.

Health projects require extra care. Product information must not be presented as a diagnosis, regulated-product workflows need professional and regulatory review, and sensitive health or customer information needs stronger access controls than an ordinary content site.

This project also teaches an important professional lesson: building for a client means respecting ownership. I can design, code, deploy and improve the platform, but the business and its health services belong to the client.

OCL therefore belongs in my portfolio as client work and as evidence of the kinds of systems I can build across domains. It is not presented as one of my personal companies.

A useful way to understand this subject is through four practical areas: a public health and pharmacy website, product catalogue and marketplace foundations, health publishing, administration and developer infrastructure and careful separation between client ownership and the builder's role. Each area looks simple when described in isolation, but the real challenge appears when they have to work together. That is why the portfolio is organized as a connected system instead of a collection of disconnected pages.

The first area, a public health and pharmacy website, affects the foundation of the experience. Users need a clear reason to arrive, a clear way to understand the product and a clear next action. A strong page reduces friction by answering the visitor's obvious questions before asking them to do anything complicated.

The second area, product catalogue and marketplace foundations, is where product decisions become technical decisions. Data structures, APIs, permissions, content models and deployment workflows have to support the experience. A feature that looks small in a mock-up can require several backend components in production, so dependencies should be considered early.

The third area, health publishing, administration and developer infrastructure, is where quality becomes visible. A product can be functional while still being difficult to understand, difficult to trust or difficult to discover. Documentation, metadata, internal links, verification, analytics and useful content all contribute to the experience.

The fourth area, careful separation between client ownership and the builder's role, points toward the future. Good systems leave room for additional features without forcing every future requirement into the first release. A staged roadmap can keep the first version focused while preserving an architecture that can grow into a larger vision.

Another important consideration is audience. A visitor should not need to understand the founder's entire technical stack before understanding the value of a page. Technical depth can be available for developers while the primary explanation remains accessible to readers, authors, customers and collaborators.

Measurement also matters. Analytics should answer useful questions: which pages are being discovered, where visitors stop, which articles attract attention and which project links people follow. Measurement should support product decisions rather than becoming a collection of numbers with no action attached.

Performance is part of the same conversation. A large portfolio can accumulate images, scripts and third-party services quickly. Lazy loading, optimized images, sensible fonts, stable layouts and careful client-side JavaScript help keep the experience responsive, particularly for visitors on mobile networks.

Trust is another layer. Clear ownership, accurate biographies, legitimate external links, transparent policies and obvious contact routes make a site feel more dependable. Trust is especially important when a portfolio discusses books, authors, AI products, technology news or services operated by other organizations.

Security should be designed into the workflow. Secrets belong in protected environment variables, forms need validation, external integrations need controlled permissions and administrative actions should be authenticated. A polished interface cannot compensate for an insecure backend.

Search discovery benefits from the same structure. Each important entity should have a stable URL, a descriptive title, a useful description and internal links that explain its relationship to other pages. Images should have meaningful alternative text, while social previews should provide a clear title, description and representative image.

For a founder building several projects, documentation is also a memory system. An article can record why a technical choice was made, what failed during deployment, what users need to know or what a product is intended to become. Months later, that record can prevent the same decision from being rediscovered from scratch.

The most useful content also includes limitations. Saying what a system cannot yet do is not a weakness; it helps users understand the current release. Future capabilities can be documented as plans without presenting them as existing functionality. That distinction keeps a growing portfolio honest.

There is a human side to all of this. Technology projects exist because someone has a problem, curiosity, story or ambition. The strongest portfolio pages connect technical work back to people: the developer learning a concept, the reader finding a book, the author reaching a new audience or the visitor looking for a collaborator.

This is why I treat the portfolio as an evolving system rather than a finished résumé. The site needs room for new projects, new books, new articles, new experiments and lessons learned from production. Its architecture should make those additions easier instead of requiring a redesign every time something new appears.

The practical workflow is therefore simple even when the ecosystem is large: define the purpose, model the information, build the smallest useful version, test it, document it, connect it to related pages and improve it from evidence. Repeating that loop is more sustainable than trying to predict every requirement before the first release.

For readers, the result should feel like a useful digital headquarters. For developers, it should expose enough technical thinking to be credible. For authors and creators, it should provide discovery and promotion surfaces. For collaborators, it should make the work and the route to contact clear. Those goals can coexist when information architecture stays disciplined.

Finally, this article is part of a larger knowledge library. The value of a library is cumulative: one article answers one question, another records one project decision, and another introduces a book or creator. Over time those pages create a searchable record of the work itself. That is the long-term reason to keep documenting, improving and publishing.

The first principle is to start with the user rather than the technology. A project can have an impressive technical stack and still fail to communicate its purpose. Clear language, predictable navigation and a useful first action reduce the distance between a visitor and the value of the product. For a growing ecosystem, this means every major page needs a reason to exist. A project page should explain a project, an article should answer a question, an author page should introduce an author and a contact page should make communication straightforward.

The second principle is architecture. As a website grows, the number of relationships grows with it. Projects connect to articles, authors connect to books, products connect to domains and technical decisions connect to future features. A structured content model makes those relationships easier to maintain. Instead of treating every page as an isolated document, the site can treat information as reusable entities. That approach is especially valuable when a founder is working on several products at the same time.

The third principle is accuracy. Ambition is useful, but a portfolio should distinguish between what exists, what is being developed and what is only a future direction. This matters for technology projects and for publishing content. If a feature is planned, it can be labeled planned. If a deployment is an experiment, it can be labeled accordingly. If an author has not supplied a social profile or official synopsis, the page should not invent one. Accuracy is a long-term asset.

The fourth principle is security. Public source code should not contain private API credentials. Application secrets belong in protected environment variables or a suitable secret-management system. Authentication and authorization need explicit design. Forms need validation. External integrations need controlled access. As the portfolio grows into real products, security becomes part of the product experience rather than a final checklist.

The fifth principle is verification. Modern development can move quickly, especially with AI-assisted coding, but speed makes testing more important rather than less important. A production build can reveal syntax errors that are easy to miss in a long file. Browser checks can reveal broken navigation. Runtime logs can reveal failures that only appear with real requests. A dependable workflow is therefore build, inspect, fix, redeploy and verify.

The sixth principle is content depth. Long articles are useful when they explain something that deserves detail. They can document a project decision, teach a technical concept, introduce an author or analyze a current development. The objective is not to add words merely to reach a target. A long page should earn its length by giving the reader more context, examples, decisions and practical takeaways.

The seventh principle is internal connection. A large portfolio should not force every visitor to return to the homepage before finding the next relevant thing. Articles can link to projects. Project pages can link to articles. Author features can link to books. A central directory can link to external sites. This creates a natural path through the ecosystem and gives every page a useful next step.

The final principle is iteration. A portfolio this large cannot be considered finished after one deployment. New projects will appear, old deployments will change, articles will need updates and product status will evolve. The correct goal is therefore not a permanent final version. It is a maintainable system that can keep growing without losing clarity.

Part of the Ibrahim Akanni Ahmad portfolio and knowledge library.