DEV Community: duncan muriithi

Why "here's a list of grants" isn't the product founders actually need

duncan muriithi — Fri, 28 Aug 2026 18:42:53 +0000

Every funding-discovery tool for startups eventually converges on the same MVP: scrape or manually curate a list of grants/accelerators, put it behind a search bar, ship it. It's the obvious build, and it's also the wrong place to stop, for a specific reason worth unpacking.

The list is not the bottleneck. The application is.

A founder searching "grants for fintech startups Kenya" doesn't lack information — Google already half-solves that. What they lack is a way to turn "I qualify for this" into "I submitted a strong application for this" without burning a weekend per opportunity writing to a rubric they've never seen.

That's the design decision behind Startup Map Hub, and it's the part worth discussing technically. The funding directory (110+ opportunities, 8 countries, refreshed weekly) is genuinely free — no gate, because a catalogue isn't the product. What's paid is the drafting layer: a Gemini-backed service that takes a founder's uploaded pitch deck and financials as context and generates a real first-draft application against a specific opportunity, rather than a generic template filled with placeholder text.

The interesting engineering constraint here is grounding: a generic LLM call produces generic funding-application prose — the kind that reads as obviously AI-written because it has no specific facts to anchor to. Feeding the founder's actual deck/financials as inline context is what keeps the output specific enough to be useful, versus "we are a passionate team solving a real problem" filler that every reviewer has learned to skim past.

The broader thesis: in any "discovery + drafting" product, the discovery half is commoditized fast — anyone can scrape a list. The defensible half is whatever makes the drafted output actually specific to the user, and that only works if the product treats grounding as core architecture, not a prompt-engineering afterthought.

Disclosure: I'm affiliated with Startup Map Hub, which I'm using here as the worked example.

Why "AI roofing" estimators stop at the tape measure

duncan muriithi — Thu, 27 Aug 2026 06:52:29 +0000

Disclosure: I'm affiliated with McQueen Roofing, which I use below as the worked example.

Point a computer-vision model at satellite or aerial imagery and it will tell you, with decent accuracy, the area of a roof, its pitch, and how many facets it has. That's a solved problem now — half a dozen companies do it well. Type "AI roofing estimate" into a search bar and almost everything you find is some flavor of that: a geometry engine wearing a marketing headline.

The part nobody productizes well is what happens after the measurement. A roof area and a pitch angle are not an estimate. An estimate is a priced, itemized list: field shingles, ridge and starter courses, underlayment, ice-and-water shield, drip edge, flashing, ventilation, tear-off, labor — each one costed at current material and labor rates, each one sized off a waste factor that should vary with how complicated the roof actually is (a simple gable wastes a lot less material than a roof with nine facets and short runs everywhere).

That's the part I think is the real moat, and it's a reasoning problem, not a vision problem. You need:

A waste-factor model that responds to measured complexity (facet count, cut density) instead of applying a flat 10% to every job.
Current line-item pricing that doesn't go stale, because a re-roof has a dozen-plus line items and any one of them being wrong or missing changes the bottom line.
A way to flag when a quote — yours or a contractor's — is missing a line item entirely. This turns out to be one of the more useful things you can do with the output: most quote disagreements aren't actually about the roof, they're about undisclosed differences in scope.

One implementation detail I'd argue matters more than it gets credit for: tagging every number in the output with how it was produced — measured, derived, assumed, user-provided, or allowance. It's a small thing, but it's the difference between an estimate you can audit and one you have to trust blindly. McQueen Roofing does this — a report where every line says whether it came from the imagery, from a calculation, from a stated assumption, or from a flat allowance, rather than presenting everything with the same false precision.

Pricing-wise it's structured as a free browser estimate (footprint-based, no measurement) and an $18 one-off charge for a measured roof — no subscription. The gate sits at the same line as the actual cost: nothing is charged until the measurement call happens, and a failed measurement refunds itself as credit rather than eating your money on a roof it couldn't read.

None of this is a knock on the pure-measurement tools — accurate geometry is a real, hard problem and it's necessary input. It's just not sufficient. The estimate is the part that turns a rooftop scan into a number someone can actually act on, and that's where I think most of the "AI roofing" category is currently underbuilt.

Stop taking screenshots for your demo videos. Paste your GitHub repo instead. 🤯🚀

duncan muriithi — Sat, 01 Aug 2026 19:58:07 +0000

Hey DEV community! 👋 I'm Duncan.

If you are anything like me, you love building apps but absolutely dread making the demo videos for them. The endless cycle of screen recording, taking static screenshots, importing them into a heavy video editor, and fighting with keyframes is exhausting.

I wanted to see if we could automate the absolute worst parts of this workflow for developers. I think we finally did it.

Today, I'm super excited to share the first phase of Brand Narratives AI.

🛠️ How it works: No screenshots required
Instead of relying on clunky screen captures, we built an engine that reads your code directly.

You just paste your GitHub link, and our engine parses it to automatically rebuild your app's exact design natively inside our video editor. Because we are reconstructing the actual UI elements rather than just snapping a flat PNG, every piece of your interface remains fully editable in the canvas.

🔮 What’s Next: Auto-Animation
This is where it gets really fun. Because our engine is actually parsing your code rather than just looking at pixels, it understands your app's semantic structure.

In our next update, it will use that context to act as your personal automated motion designer. Since it knows exactly what it's looking at, it will know that a list element should automatically slide in item-by-item, or that a popup modal should bounce into view. It will animate your app based purely on how you built it.

🧪 Try it out!
I would love for you to try out the first phase today. Drop a GitHub link into the engine and see how it handles your UI.

Link: [http://brandnarrativesai.com]

Let me know what you think in the comments, and definitely let me know if you run into any weird edge cases. Happy to answer any questions about how the engine works under the hood!

Happy building! 💻✨