Engineering insights
Research drawn from the projects in this site's portfolio, including work done as employees of other companies, rather than industry commentary. Each piece states what its dataset can and cannot show.
What the 26 DevoraX Portfolio Entries Show About Stacks and Links
The 26 entries in the DevoraX portfolio, counted field by field: whose work each was, which links a reader can open, and which stacks recur.
2,400 words · data-backed
React Native vs Flutter: What 12 Cross-Platform Builds in One Portfolio Show
Twelve cross-platform builds from the DevoraX portfolio, compared by store presence, backend and context, and what the data cannot settle.
2,533 words · data-backed
Supabase vs Firebase for Marketplace Backends: What 10 Portfolio Builds Show
Ten builds from the DevoraX portfolio, eight naming Firebase and two Supabase with no overlap: what they show about product shape, and what they cannot.
2,700 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 falls in three real marketplaces from the DevoraX portfolio.
3,014 words · data-backed
What a $3,000 MVP Budget Actually Gets You (And What It Does Not)
What a $3,000 MVP budget buys and what it does not, checked against the published $2,900 DevoraX starting tier and five web builds from its portfolio.
3,402 words · data-backed
Where does this research come from?
Every article here is derived from the same source: the 26 entries in this site's portfolio, their technology stacks, the platforms each one runs on, and the public links behind them. Those entries are not all DevoraX client work. Many are products Sameem worked on as an engineer at other companies, some have no public link, and a few links are demo builds; each project page says which. 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-six entries 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 small portfolio, shaped by the employers Sameem worked for, the clients 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.
It cannot tell you how these products perform in use. The portfolio publishes no usage, revenue or uptime figures, because none could be checked against a public source. The only figures it carries are ones a reader can verify, such as a download band on a store listing. 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.