What We Measured Across 25 Production Builds

What exactly is in this dataset?

The dataset is one agency's delivery record: 25 production projects, each stored as a structured row with a title, a category label, a tag list, a declared tech stack, a problem/solution/result narrative, a stats object and three link fields for web, Android and iOS. All 25 rows carry a non-empty problem, solution and result. The stats objects hold 95 entries in total. Fifty-seven of those were captured as quantified values in the aggregate pass; the other 38 are purely qualitative strings such as "Bank-grade", "Real-time" or "High". Nineteen of the 25 projects contribute at least one quantified value and six contribute none. Eighteen projects store at least one URL. Every figure below comes from counting those rows directly. Nothing is estimated, extrapolated or benchmarked, because no benchmark was run, and wherever the precomputed aggregate file disagrees with a direct recount of the rows, this article publishes both numbers instead of quietly choosing one.

How many of the 25 builds store a link a reader can open?

Verifiability is worth counting first, because a portfolio claim nobody can open is not evidence. Eighteen of the 25 builds store at least one URL, which is 72% of the record. Counting by the link's actual domain rather than by which field it sits in, 15 store a web address, seven store a Google Play URL and seven store an Apple App Store URL. Those rows overlap, since one project can publish to all three surfaces, so they deliberately sum to more than 25. One correction is baked into the table. The Three28 Creator Platform row stores an App Store URL inside its android field, so a naive field-based count reports eight Android and six iOS; counting by domain gives seven and seven. Seven projects, 28% of the record, store no link at all. The rows give no reason for that, so none is offered here.

What shipping shapes appear in the record?

Grouping the same 25 builds by published surface, rather than by link type, gives mutually exclusive buckets that sum cleanly to 25. Web-only is the largest group at nine projects, 36% of the record. Five projects, 20%, publish to web, Google Play and the App Store together. Three reach a mobile store with no web surface at all: two on Google Play only and one on the App Store only. One publishes to web and the App Store without a Play listing. Seven store no link. The pattern in our record is that full three-surface delivery is the exception rather than the norm, and that a single web surface is the most common shipping shape by a clear margin. That is a statement about what these 25 clients asked for and what reached a stored link, not a claim about the market. A different 25 projects would redistribute these buckets.

Which technologies appear most often across the 25 builds?

Technology frequency is counted with one explicit rule: a project counts once for a technology if that name appears in the project's tag list or among its declared tech stack entries. Prose mentions inside descriptions are excluded, because prose is inconsistent between rows. Under that rule Node.js and AWS tie at nine projects each, React.js follows at eight and Firebase at seven. The source file disagrees with itself here and the disagreement is worth naming: its top_technologies list gives AWS eight and React.js seven, while its stack_counts field gives nine and eight. The gap is a single row, Food Magnet: Vender, whose declared stack entries read "AWS Lambda Functions (Backend)" and "React.js (Admin Dashboard)". Under the rule as written those count, so this table publishes nine and eight and flags that an exact-string match would return one fewer for each.

Why should the technology counts be read as a floor?

The technology table is a floor, not a census, and the record shows exactly why. Twenty of the 25 projects list precisely two tech stack entries, typically one frontend and one backend. Only five list more, and only one lists eight. A list that stops at two names cannot describe a stack that runs to a dozen dependencies. The proof is in the narratives: MongoDB, Redis, Socket.io, PostgreSQL and Vercel are each described in one or two project write-ups, yet every one of them scores zero across all 25 tag and tech stack lists. The S3 storage service is named in five narratives and in no tag or recorded tech stack. Relaxing the rule to a substring match across the narrative prose as well raises Node.js from nine to 13 and AWS from nine to 13. Read every line in the technology table as a minimum.

Does the record favour React Native or Flutter?

Eleven of the 25 builds name a cross-platform mobile framework in their tags or declared stack: six React Native and five Flutter. The two sets do not overlap at all. No row uses both, and no row names a native-only stack such as Swift, SwiftUI, Kotlin or Jetpack Compose anywhere in its tags or techstack. Of the six React Native projects, four store a public store listing; of the five Flutter projects, three do. Within a sample this size the gap between six and five carries no statistical weight, and the record cannot test whether framework choice relates to anything else, so that question sits in the list of things this dataset cannot settle. What the record does support is narrower: across 11 mobile builds here the default was cross-platform, and not one of the 25 rows declares a native iOS or Android toolchain.

What kinds of outcomes do the stat fields hold?

The 57 quantified values are not one kind of thing, and treating them as a single pile overstates what they show. Twenty-five are scale or volume counts across 13 projects: active users, completed orders, verified vehicles. Nine are rate, growth or efficiency figures across seven projects. Eight are satisfaction or rating values across eight projects. Five are explicitly revenue-labelled figures across five projects. Five are reliability or technical measures across three projects. The last five are not outcomes at all but configuration or compliance descriptors, such as encrypted storage or GDPR and ISO 27001 alignment, that were captured alongside genuine measurements. Stripping those out leaves 52 numeric values. One judgement call is worth flagging: Dooz's "1.2B+ JD Total Transactions" is a monetary figure counted under scale, because the row labels it transaction volume rather than revenue.

What shape do the 57 recorded values take?

The shape of the values says as much as the values do. Each of the 57 was assigned to exactly one bucket, in this order: percentage, monetary, rating scale, rounded count, exact-looking count, then non-numeric descriptor. Nineteen are percentages, and five of those 19 are the identical string 98%, sitting on five separate projects. That is the shape of a rounded self-assessment rather than five independent measurements landing on the same figure. Seventeen more are rounded floors ending in a plus sign, like "20,000+" or "2.4M+", which are approximations by construction. Only seven read as exact instrument counts, such as "12,778" and "128,540". Two counts land on 52 here by coincidence and should not be confused: 52 of the 57 values are numeric, and 52 of the 57 are distinct strings. Only 98% and 100% appear more than once.

What does the record show about stack concentration?

Two concentrations stand out in our record. First, backends: nine rows name Node.js and four name NestJS, with no overlap between the sets, so 13 of 25 builds, 52%, run a Node-family backend. Second, managed backend services: seven name Firebase and three name Supabase, again with no overlap, so 10 of 25, 40%, lean on a backend-as-a-service rather than a self-managed data layer. Taking React.js, Next.js, React Native and the bare React tag together gives 18 of 25, 72%, touching the React ecosystem somewhere. Container orchestration is the opposite story: Kubernetes appears in exactly one row. The self-assigned category labels agree, with six rows titled "Node.js Backend & AWS" and four "React Native & Node.js". Nothing in the record says a house standard was imposed; this is simply what the stored stacks add up to.

What would make this record more citable next time?

The most useful output of counting your own record is the list of things you wish you had captured. Five gaps are visible. No recorded figure carries a measurement date, so a revenue figure cannot be placed on a time basis. No percentage change is paired with a baseline, which is what turns a reported improvement into evidence. Nothing we store records who supplied or measured any value, so provenance has to be assumed rather than read. The tech stack list caps most projects at two entries, which is why the technology counts are a floor. And one project stores an App Store URL in its Android link, the kind of quiet error that inflates a platform count. The only date any project carries is the timestamp from when its entry was created, which dates the CMS entry rather than the build. None of these are hard to fix at capture time and all are impossible to fix retroactively.

Limitations

• n=25 from a single agency. These are one team's clients, sectors and budgets, not a random or representative sample of software projects.
• Provenance is not stored. No field in either source records who supplied or measured any stat value. None were independently audited, instrumented by us, or checked against a client's analytics, so every outcome figure should be read as self-reported.
• No control group and no baseline. A reported '20% operational efficiency increase' has no recorded before-state or comparison condition, so it cannot be treated as a measured effect.
• The technology counts are a floor, not a census. 20 of the 25 projects cap their recorded tech stack at two entries, and MongoDB, Redis, Socket.io, PostgreSQL and Vercel each appear in project narratives while scoring zero across all 25 tag and tech stack lists.
• The source aggregate file disagrees with itself on two counts: its top_technologies list gives AWS 8 and React.js 7 while its stack_counts field gives 9 and 8. This article publishes the values consistent with its stated rule (9 and 8) and names the discrepancy rather than hiding it.
• Stat values carry no measurement date and no consistent time basis. '$1.2M Total Revenue' and '$28,450 Monthly Revenue' are not comparable quantities.
• 21 of the 57 values are rounded approximations ending in a plus sign, such as '20,000+' and '2.4M+'. They are floors stated by the source, not precise readings.
• Outcome metrics are unevenly distributed: 19 of 25 projects supply all 57 and 6 supply none. Food Magnet: Vender stores 11 stat entries, none of which is a quantified outcome.
• One row stores an Apple App Store URL inside its android field. Counts here are taken by link domain, which corrects for it, but a field-based count of the same data would report 8 Android and 6 iOS.
• Links were counted as present in the rows. They were not fetched or checked live, so 'public link' here means 'a URL is stored', not 'the page resolves today'.
• The record contains shipped projects only. There is no entry for cancelled, abandoned or failed work, making every pattern here survivorship-limited.
• The only timestamp on any row is created_at, which dates the CMS entry (8 rows in 2025, 17 in 2026) rather than the build or the delivery.

What this data cannot answer

• Is React Native faster, cheaper or more maintainable than Flutter? The record holds no benchmarks, build times, bundle sizes, crash rates or defect counts for either.
• Does framework choice relate to whether an app reaches a public store? With 6 React Native and 5 Flutter projects and no test performed, the record cannot support a correlation claim in either direction.
• Did any stack choice cause any reported outcome? With no control group and no counterfactual, the record can show co-occurrence and nothing more.
• What did these builds cost, or how many developer hours did they take? No cost, effort or team-size data is stored in any row.
• How long did each project run from kickoff to launch? The only date on a row is its created_at timestamp, which dates the record rather than the build.
• How do these figures compare to industry averages? n=25 from one agency cannot establish or test an industry baseline.
• Are these products still live and maintained today? Links were read from the rows rather than fetched, and no uptime, release cadence or maintenance status is stored.
• Which technology choices failed, and why? Only shipped projects are recorded, so there is no failure data to analyse.
• Who supplied or measured each stat value? No field records provenance, so even the conservative 'self-reported' reading is an assumption rather than a stored fact.
• What is the combined end-user total across the portfolio? The user figures use incompatible definitions (active users, total users, student reach, workers supported) and 21 of 57 values are rounded floors, so they cannot legitimately be summed.