Dennis Njuguna

If your product is slowing down as usage grows, the issue probably is not your infrastructure. It is the architecture underneath it. Did you consciously choose your pagination approach, or did it just happen? If the latter, it might be worth a second look.

Your investors will tell you to fix marketing. Your engineers will tell you to upgrade the infrastructure. Neither conversation will mention pagination. And that silence is expensive.

Your investors will tell you to fix marketing. Your engineers will tell you to upgrade the infrastructure. Neither conversation will mention pagination. And that silence is expensive.

Making sales but cash feels tight? Revenue ≠ cash. Late or messy invoicing slows payments → kills momentum. Not a sales problem. A workflow problem. Fix the flow. Get paid faster.

Cash flow does not break at once. It slips: - late invoices - slow fixes - unclear status Each delay pushes payment out. Post-MVP, small workflow gaps = real damage. Speed up invoicing. Fix cash flow.

Post-MVP, your problem is not features. It is friction. Slow invoicing = wasted time + delayed payments. You need: - fast creation - easy edits - clear status Less friction. More cash.

Closing a deal is not the finish line. Cash is. If invoicing is slow, everything stalls: - payments delay - decisions slow Your job: shorten sale → invoice → payment Faster flow = faster cash.

Pagination is one of those decisions that gets made early, usually quickly, and then never revisited. But if your product asks users to find things, compare options, or come back to where they left off, the way you paginate shapes almost everything.

If a user runs a search on your product right now, do you know exactly how much data your backend fetches to show that first page of results? If the answer is no or not really, start here: njuguna.dev/articles/pagination-isnt-a-ui-detail--its-a-revenue-control

Most founders assume churn = weak product. More often, it’s this: Your product is good. But it’s too hard to understand, too quickly. And users don’t wait around to figure it out.

Users can move through your product flow smoothly, find value, and get excited. But if the final step asks too much of them, they hesitate. And hesitation at the finish line is expensive. It's not a traffic problem. It's a completion problem.

When conversions are low, the instinct is to pour more in at the top. Run ads. Push more users through. Hoping numbers move. They rarely do. The problem is usually at the very bottom. Checkout. Pricing. Signup. Payment confirmation. Approval flow. It's where trust holds or breaks.

Founders need less friction.

Bad invoicing isn’t an admin issue. It’s a growth issue. When the workflow is clunky, you pay for it twice: - in delayed cash - in lost time And those two things compound fast.

Leadership is a glue that holds together production-grade apps today and tomorrow.

Most founders do not have a traffic problem. They have a delusion problem. They keep paying for clicks while refusing to look at what happens after the click. That is how revenue leaks happen. Read more here:

Deep architectural understanding is what really matters right now. AI can generate syntax and structure, but it doesn’t own the system-level thinking.

Understanding architecture at a deeper level matters more than anything else. AI types syntax, but it didn't replace the human mind.

Blind trust is using AI as a guide. Knowing the answer and what's happening under the hood is using it as a tool.

If shipping feels harder than it did 6 months ago, pay attention. That usually shows up as: 🔴 integrations taking too long 🔴 releases slipping 🔴 support tickets rising 🔴 engineers burning time on “small backend issues.” 🔴 roadmap confidence dropping A lot of the time, they’re API problems.

The best teams don’t move faster because they work harder. They move faster because they build systems that are: ✅️ consistent ✅️ predictable ✅️ secure ✅️ well-documented ✅️ ready to scale That’s what production-grade actually means.

What separates software engineering from other engineering disciplines is having a strong business acumen. The ability to understand business in detail, give clients real insights, and take charge of projects in the RIGHT direction for the good of the client is the biggest flex.

When your API is inconsistent, under-documented, or fragile under load, the whole business feels it. Not just engineering. The product slows down. Partners wait longer. Customers hit friction. Growth gets more expensive. That’s why: APIs are not plumbing. They’re growth infrastructure.

In real life, software engineering is not for the faint-hearted.

Most founders don’t realize their app is slowing growth until the team starts shipping with hesitation. That’s usually the first real warning sign. Small changes take longer. Releases feel riskier. Performance becomes inconsistent. The product works, but it’s getting harder to move.

Thinking of AI as a junior who started 2 days ago is a much better approach than approaching it as mid-level, because it'll screw you up!

If your product touches revenue, retention, customer data, or core operations, then “we’ll clean it up later” is rarely harmless. It’s often the moment hidden costs begin compounding. If your app is live and growth is starting to expose cracks in the foundation, this is the moment to fix them.

A lot of founders think scaling problems show up as traffic issues. They don’t. They usually show up first as delivery drag. More rework. More QA. More caution. Less momentum. This is why I keep saying: 𝐒𝐜𝐚𝐥𝐚𝐛𝐥𝐞 𝐬𝐨𝐟𝐭𝐰𝐚𝐫𝐞 𝐢𝐬 𝐧𝐨𝐭 𝐚𝐧 𝐞𝐧𝐠𝐢𝐧𝐞𝐞𝐫𝐢𝐧𝐠 𝐥𝐮𝐱𝐮𝐫𝐲. 𝐈𝐭’𝐬 𝐚 𝐛𝐮𝐬𝐢𝐧𝐞𝐬𝐬 𝐚𝐝𝐯𝐚𝐧𝐭𝐚𝐠𝐞.

open.substack.com/pub/dennisnj...

Having clear goals and letting the team be able to even operate seamlessly when you are away is the highest level of ownership, which leads to winning together 💪

The finish line (checkout, onboarding, payment, or approval flow) deserves the same attention you gave to the onboarding. The same care you gave the landing page. The same scrutiny you gave the pricing. Because that's where the money actually moves.

I believe AI will change the way we work — it already is. But there’s a big difference between a tool that amplifies expertise and one that replaces it. “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler

open.substack.com/pub/dennisnj...

Understanding AI capabilities starts with understanding the fundamentals, not chasing the latest model releases.

You learn more especially when they ask deeper-level questions. It sharpens understanding.

AI won’t replace architecture decisions, but it can significantly speed up the analysis and planning because architectural decisions still require context, trade-offs, and real-world production experience. It's a strong accelerator for analysis and planning.

When seniors are guiding juniors, they should guide them the way they wish they had been guided when they were starting.

Product thinking is product ownership, which scales value 💯

open.substack.com/pub/dennisnj...

Understanding code clearly results in robust systems. Understanding the business and tying it to the relevant outcomes leads to impactful business growth.

Great engineers are producers, not just consumers

open.substack.com/pub/dennisnj...

When building production-grade systems, auditing thought processes leads to future-proof outcomes that actually compound and make businesses profitable.

It is one thing to prompt your favorite LLM for brainstorming purposes; it's a whole other universe when you're prompting because the only language you know in that code is English. To be clear, IF YOU DON'T UNDERSTAND IT, DON'T SHIP IT!

LLMs are not engineers. They are like very powerful mirrors, but mirrors do not choose where to look. They do not decide what matters. They do not notice when the system they are producing is drifting into incoherence and bullshit.

When an LLM can generate a Rust compiler, it means that the compiler design already existed, documented and discussed, taught and debated, refactored, and explained for years by HUMANS. The model did not invent it. It replayed a compressed shadow of collective effort. That's not an achievement!

Pretending LLMs are minds is how you build systems that look impressive on day one, and quietly result in failures across Big Tech infrastructure that no one wants to discuss.