Engineering insights
Research drawn from our own delivery record rather than industry commentary. Each piece states what its dataset can and cannot show.
What We Measured Across 25 Production Builds
One agency's 25-project delivery record, recounted field by field: stored public links, stack frequency, and 57 stat values with their known defects.
2,431 words · data-backed
React Native vs Flutter: Evidence From 11 Production Apps
Eleven shipped cross-platform apps, counted from the delivery record: which reached both app stores, which backends recurred, and what the data cannot settle.
2,294 words · data-backed
Supabase vs Firebase for Marketplace Backends: What 25 Shipped Projects Show
Ten shipped builds, seven on one backend and three on the other, with zero overlap: what one agency portfolio shows, and what it cannot.
1,460 words · data-backed
Sharetribe vs Custom Marketplace Development: Where the Line Actually Falls
Where Sharetribe is the right answer, where a custom marketplace build is, and how that line fell inside three marketplaces one agency actually shipped.
1,681 words · data-backed
What a $3,000 MVP Budget Actually Gets You (And What It Does Not)
What a $3,000 MVP budget actually buys, and what it does not, checked against our published $2,900 starting tier and five live builds.
2,511 words · data-backed
Where does this research come from?
Every article here is derived from the same source: the record of work we have actually delivered. That is 25 production builds, their technology stacks, the platforms each one shipped to, and whatever outcome figures the clients reported back to us. Nothing is drawn from a survey we did not run, a benchmark we did not measure, or an industry report we did not read in full.
That makes these articles unusual in one specific way, and it is worth being direct about it. Twenty-five projects is a small sample. It is large enough to show which technology choices recur and where they cluster, and far too small to support a general claim about the industry. Where an article reports a proportion, the denominator is stated next to it so you can judge the weight of the finding yourself.
What can this data not tell you?
It cannot tell you what is true of software projects in general. It is one agency's book of work, shaped by the kinds of client who approached us and the kinds of problem we were asked to solve, so it carries that selection bias in every direction at once. It also cannot tell you much about failure, because the projects that reach a portfolio are the ones that shipped.
Outcome figures come with a second caveat. Where a case study reports user counts, order volumes or uptime, those are numbers the client reported to us or took from their own systems. We did not independently instrument or audit them, and we present them as client-reported for that reason. Each article restates the limits of its own dataset rather than relying on this page to have done it.
Where is the underlying work?
The projects these articles are built from are published in full. Each one has a long-form engineering case study covering the problem, the architecture, the technology choices and the reasoning behind them.