How to2 min read
How much does an app cost in 2026?
There is no single number, but there is a method. Here is how we turn a rough idea into a range you can plan around, and what makes that range move.
- Pricing
- Process
Blog
What we have learned building things
Occasional, specific and written by the people doing the work. If you would rather see it applied, read our case studies or estimate a project.
Subscribe via RSSHow to2 min read
Native or cross-platform: how we actually choose
We default to Flutter for cross-platform work and go native when the project earns it. The decision comes from constraints, not fashion.
- Mobile
- Engineering
How to2 min read
What an MVP should actually contain
Most MVPs fail because they are either too small to prove anything or too large to ship. Here is how we decide what goes in.
- Product
- Startups
Tech2 min read
Integrating mobile money: what actually breaks
Card-shaped assumptions are the reason mobile money integrations fail. What changes when the wallet, not the card, is the default way your customers pay.
- Fintech
- Engineering
How to2 min read
Build, buy or adapt: choosing a learning platform
Most organisations do not need a custom LMS, and the ones that do usually know why. A decision framework from a team that builds and runs one.
- Product
- Education
Tech2 min read
Why offline-first is not optional in our markets
If your product assumes a stable connection, it will fail exactly when people need it. Designing for intermittent networks changes the architecture, not just the UI.
- Engineering
- Mobile
Tech2 min read
The API security checks we run on every build
Not a survey of every threat that exists — the specific, unglamorous checks that catch most of what we find in real reviews.
- Engineering
- Security
How to2 min read
How we estimate software, and why we quote ranges
A single number implies a certainty nobody has before scoping. Here is the method behind our estimator and what makes an estimate move.
- Process
- Pricing
How to2 min read
The accessibility checks we run before release
Accessibility fails in the same few places on almost every project. Catching them costs minutes during the build and days afterwards.
- Design
- Engineering
From our founder
More writing on kapolbrondon.com
Longer-form pieces published on kapolbrondon.com, pulled in automatically.
kapolbrondon.com
How a Product Engineering Consultant Runs an MVP Sprint
The MVP sprint reduces a product thesis to one core workflow, builds it on a multi-tenant foundation, and deploys it in 8 to 12 weeks. Here's how I scope, build, and hand over as a product engineering consultant.
kapolbrondon.com
Spring Boot Development Delivered a Live Payments Core in 10 Weeks
A field note from a fintech MVP sprint: delivering a live payments core in 10 weeks, with a scoped workflow that proves the thesis and foundations that survive growth.
kapolbrondon.com
Tailwind CSS development for regulated public sector interfaces
When a public sector tax platform demanded an auditable UI down to the pixel, Tailwind CSS development turned design tokens into a compliance asset. Here is the technical constraint and how we solved it.
kapolbrondon.com
What Strapi Development Taught Me About Fintech Correctness
Strapi development rarely gets linked to fintech. When I built a content layer for a payments dashboard, the disconnect became a liability. Here's the working principle that keeps both sides honest.
kapolbrondon.com
Launching a Product with a Remote Software Engineer MVP Sprint
Discover how my MVP Sprint engagements deliver a functional product, ready for real users, in just 8-12 weeks. I detail our approach to focusing on critical workflows and building robust foundations for future growth.
kapolbrondon.com
My MVP Development Process: Getting Real Products to Market
I explain the structured approach I use for MVP development sprints. You will learn how we move from an initial idea to a deployed, customer-ready product in 8 to 12 weeks, focusing only on core functionality that proves your thesis.