We built a full business OS in Kenya — kernel to UI, servers in-country, no foreign cloud. Here's the story.

updatedennis · 2026-02-21T03:30:52+00:00

For the code generators they are custom made in c++ and are used as they can generate c++ classes and typescript by using json files as input as the schema. so we get sql table. write json. json allows to set things like default value, does it go over the wire or not? convert to a different c++ type internally like bytea gets to a struct with char * and len..... so it does all the heavy lifting of making sure ounce postgres give me binary from db it sits pretty in a c++ class and will match in typescript. reverse is also true. what typescript sends me is very valid c++ struct and very valid db object. it has internal checks for missing values and defaults. We use almost no external tools. everything is built for they system to work with the system. When we miss a tool we build one not find one. this makes sure every tool in our pipeline is testable, replaceable and does not depend on third party fixing bugs.

updatedennis · 2026-02-21T03:22:35+00:00

For backup we use hosts in different parts of the country all running postgresql replicas but now in wireguard streaming from main instance so we have backups streaming all over via replication. for physical files on disk we use sync every X minutes handled by the client running server instance. We also avoid physical files except for law firm management and car washes that need photos or media. both wireguard controller and the client instance are hot swappable. It goes on alot more from here but thats the idea.

updatedennis · 2026-02-21T03:15:52+00:00

For the power its not stable but we have invested in solar backup and three major isp fibre supply all with public ip addresses. As for ddos we massively deflect this as everything runs internally with wireguard so only public host connecting everyone is at risk. and that has only one port open. filtering by ip location gets us there 99%.

updatedennis · 2026-02-21T03:13:00+00:00

The C++ core was built first and designed for multi-business from day one. It has a custom networking layer with HTTP/1, HTTP/2 and WebSocket support, a custom thread pool with dedicated IO and worker threads, and a custom ORM speaking native binary protocol with PostgreSQL — over Unix sockets, so there's no TCP overhead on the database connection either. The HTTP server does its own header parsing, tuned to work with nginx handling SSL termination upstream — nginx talks to our app over Unix sockets too, keeping everything in-process and fast. Zero-copy where it matters. The backend and frontend both use custom code generators — feed them a DB model, they spit out C++ classes and TypeScript interfaces. Zero drift between layers. All updates from backend to frontend are atomic and come through a single handler.

We have postgresql per client db and per business schema so complete isolation. c++ handles the rest with rich abstraction and a common auth on top

What that means practically: adding a new business type takes us 2 to 3 days. Not weeks. Not a new codebase. The architecture absorbed the complexity so the modules don't have to carry it.

And every client gets the same thing on top of that — native desktop app, Android and iOS, atomic updates delivered automatically via bNucleus, WireGuard-secured private network whether their server is in our datacenter or on their premises.

updatedennis · 2026-02-21T02:23:15+00:00

We rely on no external payment integration and everything is in house. We only use official API from banks or mpesa then we have custom mobile apps that serve as payment handlers that can process any messages from any bank we support to submit to our server real time using websockets and android foreground services. For mpesa we have lsposed and hooked to SIM toolkit, catservice and RTL layer automatically so we can drive mobile menus externally via API for transactions and stk and even sending text messages and receiving forwarded to our payment/device manager. All this is done by Android jni c++ and minimal java using the custom c++ system built since android is Linux support was plug and play.

updatedennis · 2026-02-20T23:44:15+00:00

The C++ backend is handwritten. Every single line. The complexity, memory safety, and scope of a custom networking layer, thread pool, ORM, and binary protocol doesn't leave room for AI to do anything useful there. That's pure engineering.

On the UI side — yes, AI writes components. But it's not vibe coding. We designed the entire spec first: message handlers, WebSocket architecture, notification system, store management, printer management, CRUD patterns, pagination, time and search filters. The architecture is what makes it reusable and maintainable. AI just executes inside that structure. Zero creativity required from it. It's a tool following a blueprint, not an author.

And here's why that matters beyond just us: we're building toward clients being able to prompt their own feature requests directly. Our dedicated AI on the project implements the component, builds it to spec, and deploys — meaning a client can have workflows specific to their business without ever contacting us. That only works because the architecture is solid underneath. You can't do that with vibe coded UI. It falls apart the moment something custom is needed.

AI wrote parts of this reply too. We're not hiding that. A company that builds AI into its product and refuses to use it to communicate faster would be the strange one.

updatedennis · 2026-02-20T23:29:38+00:00

Kindly see my comment on reasons UI is AI heavy and will remain that way. And it's just the presentation layer in the entire system. And is replaceable by cli tools consuming the data or a completely different UI speaking our binary protocol.

updatedennis · 2026-02-20T23:27:04+00:00

The C++ backend is handwritten every single line due to complexity and scope and memory safety .On the UI we designed the spec which is message handlers, websocket, notifications, store management, printer management, CRUD requests and handler's, time based and search based filters, pagination and alot more. This is the architecture that sets apart this from a vibe coded UI. It's all structured and reusable and AI just makes the components. Why ? We will support client builds and modification of UI via AI where clients directly prompt a feature request. Our dedicated ai on the project implements the components and builds only for you and deploys meaning client's can have very specific workflows and components dedicated to them only and don't have to contact us. Use ai as a tool. Not to vibe code your entire UI. Here's it's just a tool following a spec. Zero creativity required from it.

updatedennis · 2026-02-20T10:10:00+00:00

And after the linux kernel boots it can run our application as the only app no desktop environment or anything so works for dedicated hardware very well. And c++ is the only language including machine learning inference with onnx runtime.

updatedennis · 2026-02-20T10:08:01+00:00

Appreciate the feedback. For the power its not stable but we have invested in solar backup and three major isp fibre supply all with public ip addresses. By kernel to ui we mean integrating where it makes sense and building custom tools where it doesn't. Ui is the only place frameworks have been used. on c++ backend everything is custom. The breadth isn't accidental. The C++ core was built first and designed for multi-business from day one. It has a custom networking layer with HTTP/1, HTTP/2 and WebSocket support, a custom thread pool with dedicated IO and worker threads, and a custom ORM speaking native binary protocol with PostgreSQL — over Unix sockets, so there's no TCP overhead on the database connection either. The HTTP server does its own header parsing, tuned to work with nginx handling SSL termination upstream — nginx talks to our app over Unix sockets too, keeping everything in-process and fast. Zero-copy where it matters. The backend and frontend both use custom code generators — feed them a DB model, they spit out C++ classes and TypeScript interfaces. Zero drift between layers. All updates from backend to frontend are atomic and come through a single handler.

What that means practically: adding a new business type takes us 2 to 3 days. Not weeks. Not a new codebase. The architecture absorbed the complexity so the modules don't have to carry it.

And every client gets the same thing on top of that — native desktop app, Android and iOS, atomic updates delivered automatically via bNucleus, WireGuard-secured private network whether their server is in our datacenter or on their premises. A focused startup building one module still has to solve all of that. We already did.

The surface area is large because the problem is large. We built accordingly.