Independent Submission

Request for Comments: 0001

Category: Informational

C. Oraegbu

Lagos, Nigeria

November 2026

On Building Platforms and the Teams That Run Them

a.k.a. the portfolio of Charles Oraegbu

Abstract

Charles Oraegbu builds platforms and the teams that run them.

He is Lead Engineer at SearchAtlas, where he leads six engineers and owns technical direction, delivery, releases and reliability for the core backend behind 190K+ projects and 1,000+ active customers. He built platforms his team now runs, and moved on to the next one. Earlier, he architected Wowzi's cross-border payments platform and built logistics and finance data pipelines at Kobo360. He has built backend systems from Lagos for more than seven years.

Section 2 is the platforms. The rest is the evidence.

Status of This Memo

This document is not an Internet Standards Track specification. It is published for informational purposes. Distribution of this memo is unlimited.

The author is open to lead roles and contract work. To respond, write to the author.

1. Introduction

A platform is finished when a team can run it without me.

That is the job: build the platform, set the bar it ships to, hand it to a team that owns it, and move on to the next hard problem. I stay hands-on in design, review, releases and incident response, because that is where the bar gets tested.

Section 2 is the platforms I built. Section 3 is a design note, Section 4 three incidents and the calls I made, Section 5 my career and Section 6 what I am building now. A reader in a hurry MAY skip to the Author's Address.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "SHOULD" and "MAY" are used as in BCP 14 [RFC2119] [RFC8174]: MUST has no exceptions, SHOULD allows one for a good reason, and MAY is optional.

2. Platforms I Built

Five platforms I built, designed or took over, and the calls that shaped them. My team took over the first two and runs them.

2.1. One publishing service for 10+ CMS platforms
I started it from an empty repository in August 2025. It connects SearchAtlas's AI content product to 10+ CMS platforms, one connector per platform, each with its own field schema and connection test. Credentials are encrypted at rest, and the integrations are built with retries, idempotency and deduplication. My team runs it now.
2.2. The retrieval platform behind our AI
I designed the retrieval (RAG) platform that finds the source material our AI answers build on. It serves 400K+ queries a month, and my team runs it. When its database hit 100% CPU in June 2026, I scoped each ingest's stats refresh to the sources it touched and cut its key query from over 25 seconds to 1 ms.
2.3. An AI article-generation feature, taken over and made production-grade
A large AI article-generation feature had been built inside an app another team managed. I took it over and made it production-grade inside our main service: its own domain layers, articles that open as first-class editor pages, and quota that charges on delivery and refunds failed generations.
2.4. The AI article agent
I designed and built the agent SearchAtlas customers use to research, write and edit articles in a chat. It went live in July 2026, open to all users. See Section 3.
2.5. Cross-border payments at Wowzi
I architected Wowzi's cross-border payments platform: wallets, withdrawals, bank transfers, mobile-money payouts and multiple currencies. Money moves ledger-first, with reconciliation, reversals, idempotency, locking and an audit trail, and campaigns funded in US dollars are converted into local currencies before paying out. I led its market integrations from discovery through launch and production support with Product, Finance, Operations and outside providers, covering payments, KYC and local rules.

3. Design Note: The Article Agent

Problem: Our article generator turned one form into one article. I designed and built its replacement: an agent the customer works with in a chat, from research to finished article, and can keep editing by chat afterwards.
Constraints: The main app owns logins, credits and brand data. Nothing spends a customer's credits without their approval. Any pod can die mid-run.
Design: A chat gateway in the main app owns the connection, permissions and limits, and starts a short-lived Kubernetes pod for each chat. The agent in that pod researches with the customer's own permissions, proposes a brief and waits for approval before it writes the article and charges credits.
Decisions: One disposable pod per chat instead of one shared service: every chat runs the latest code, and a crash only hurts its own chat. The cost is a short wait while each pod starts.

The approval step's state lives in the gateway, not the pod, so a new pod can rebuild it after a crash.

One-click generate became an auto-approved chat, so credits are charged in one place and any article can be reopened as a chat and edited.
Result: In production since July 2026 and open to all users.
Rule: State that must survive a crash MUST NOT live in the process that can crash.

user <--WebSocket--> GATEWAY <------------ events ---------+
                     ownership, throttle, gate state       |
                       | spawn pod + RabbitMQ              |
                       v                                   |
          pod (one per chat)                               |
            DAEMON: plan --tools--> MCP TOOL SERVER        |
              |                                            |
              v                                            |
            APPROVAL GATE: user approves the brief         |
              v                                            |
            generate + charge credits ---------------------+

user
 ^ |
 | | WebSocket
 | v
GATEWAY  ownership, throttle,
 ^ |     gate state
 | | spawn pod + RabbitMQ
 | v
 | pod (one per chat)
 |   DAEMON: plan --> MCP TOOL SERVER
 |     |
 |     v
 |   APPROVAL GATE: user approves
 |     |            the brief
 |     v
 |   generate + charge credits
 |     |
 +-----+ events

Figure 1: One chat, from WebSocket to article

4. When It Broke

Three production incidents: the impact, the call I made and what it changed.

4.1. Failures Cut From 16% to Under 0.5%

Impact: In August 2026, one in six article generations failed (16%).
The call: Make the failure visible first: stall reports went to our error tracker, so the evidence outlived the crashed pods. Then fix what we control: give runs the time they need, give retries one shared time budget, and make every AI call record which path served it.
Result: Daily failures were under 0.5% on days three to six after the fix. In September I made silent failures loud: the agent now crashes and reports instead of hanging, and each model has its own failover chain.
Rule: Every call to an outside service SHOULD record which path served it.

Failed runs, share of the day's articles
Before fix |################################| 16%
After fix  |#                               | under 0.5%

Failed runs, share of
the day's articles
Before |################| 16%
After  |#               | under 0.5%

Figure 2: Failed runs, before and after the fix

4.2. Stuck Pipeline Jobs Now End on Their Own

Impact: Jobs in our content pipeline got stuck, or reported success when they had failed, and each case was being fixed one at a time. Workers were also crashing from running out of memory.
The call: Stop fixing cases. Every job in the pipeline now gets a deadline when it is dispatched, and a separate reaper ends any job that misses it. It ran in shadow mode before enforcement went live. I traced the memory crashes to workers that never recycled, and moved heavy work onto its own workers, which restart to free memory.
Result: In shadow mode it ran 20 hours in production with zero errors on its new paths. The reaper is now enforced. A stuck job ends on its own, whether or not anyone looks at it. Memory kills on the first affected queue stopped once heavy work moved to its own restarting workers.
Rule: Every background job MUST have a deadline that something outside it enforces.

4.3. A Failure Class Prevented by Design

Impact: In late June 2026, a chat edit in our AI article editor was wiping a customer's article on the first edit turn.
The call: I shipped two fixes the same day. When an earlier fix still wiped, I went after the class of bug rather than the instance: a shared listener that mistook a failed regrade for a finished generation. It was replaced with a writeback for each operation.
Result: The new design structurally prevents that class of bug. A follow-up change to the editor was checked byte for byte against production articles before release.

5. Revision History (Career)

My career, written as drafts of this document: each revision is one role, newest first. Some ran in parallel.

-06: November 2026 Published as RFC 0001.
-05: April 2025 to now SearchAtlas. Remote (USA). Senior Backend Engineer, then Lead Engineer from January 2026. Leads six engineers and owns technical direction, delivery, releases and reliability for the core backend. Built the CMS publishing service and the AI article agent, designed the retrieval platform, and took over a large AI article-generation feature.
-04: May 2023 to May 2026 Backend Engineer, Wowzi. Remote (Kenya). Architected the cross-border payments platform and led new market integrations from discovery to production with Product, Finance, Operations and outside providers.
-03: June to December 2022 Software Engineer (contract), Konstellation / Vegax Holdings. Remote (South Korea). Led 60% of a backend migration from PHP Yii to Python and FastAPI, and designed and shipped four services to production that computed indices and ingested data.
-02: September 2021 to June 2023 Kobo360. Lagos, Nigeria. Python Engineer (September 2021 to August 2022), then Senior Data Engineer (August 2022 to January 2023), then Data Engineer, consultant (January to June 2023). Built logistics and finance data pipelines in Python, SQL and Prefect, and automated every recurring client and internal report.
-01: February to October 2021 Software Engineer (contract), Weekendlabs / hiring.io. Remote (India). Shipped customer-facing features with frontend and product engineers.
-00: February 2018 to February 2021 Independent consultant. Built backend systems for clients and owned them from API design to production support.

Education: Bachelor of Computer Science, University of Lagos (2024), finished while working (revisions -00 to -04). National Diploma in Computer Science, Yaba College of Technology (2018).

6. Implementation Status

Following [RFC7942], this section records what the author is building now.

[Note to RFC Editor: please remove this section before publication, or once SubSentry launches, whichever comes later.]

Name: SubSentry
What it is: A personal-finance product built around Nigerian bank statements. It turns a statement into a clear picture of where the money goes: spending by category, subscriptions, recurring bills and bank fees, and a chat that answers questions about it.
My role: Sole builder and owner. I run it end to end: the product roadmap, architecture, the AI pipeline, the web app, deployment and monitoring.
The bar: Numbers come from code, not from the AI: an answer that quotes a figure no code produced is held back. Names and account numbers are masked before any AI model sees them.
Status: Deployed, not yet public.

7. Security Considerations

Customer data and money get the strictest rules in this document. In SubSentry (Section 6), names and account numbers are masked before any AI model sees them. In the article agent (Section 3), research runs with the customer's own permissions, and credits are charged only after the customer approves the brief or starts a one-click generate.

8. Operational Considerations

I work from Lagos (UTC+1) and have worked remotely with teams in the USA, Kenya, South Korea and India, in Python (Django, FastAPI), Go and Java (Spring Boot), with PostgreSQL, Redis, AWS, Kubernetes and RabbitMQ.

Messages sent outside Lagos working hours are queued, not dropped. Delivery is at-least-once; replies are idempotent.

9. IANA Considerations

This document has no IANA actions. The author's time zone is already registered: Africa/Lagos.

10. References

10.1. Normative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

10.2. Informative References

[DEV2024]: Oraegbu, C., "Testing serverless python applications with serverless offline + pytest", DEV Community, January 2024, <https://dev.to/charlesco/testing-serverless-python-applications-with-serverless-offline-pytest-5en9>.
[GITHUB]: Oraegbu, C., "Source repositories", <https://github.com/charles-co>.
[RFC7942]: Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, July 2016, <https://www.rfc-editor.org/info/rfc7942>.
[CV]: Oraegbu, C., "Curriculum vitae", PDF, download the CV (PDF).

Author's Address

Charles Oraegbu
Lagos, Nigeria
Local time: --:-- (UTC+1)

Email:: oraegbucharlescgmail.com
GitHub:: github.com/charles-co
LinkedIn:: linkedin.com/in/charles-oraegbu
Medium:: medium.com/@oraegbucharlesc
DEV:: dev.to/charlesco
X:: x.com/charlesco_
CV:: Download CV (PDF)

Request for Contact

Write about a role, a contract or a hard problem. Replies come from Lagos.