What the 26 DevoraX Portfolio Entries Show About Stacks and Links

What exactly is in this dataset?

The dataset is the DevoraX portfolio: 26 entries, each stored with a title, a category label, a tag list, a declared tech stack and three link fields for web, Android and iOS. It is a portfolio of products that DevoraX's founder, Sameem Amjad, has built or worked on. Twelve entries are products Sameem worked on as an engineer at other companies: five at Zencloud, four at Webrange Solutions, one at Pastel, his current employer, one at Fleact Tech and one at ivector. Four are his direct client work: Three28, Dooz, JUJU and Hear With You hired him directly. Five more have no named client, and the last five have no client and no public link.

Every figure below comes from counting the entries' structured fields directly. Nothing is estimated, extrapolated or benchmarked, because no benchmark was run. Free-text descriptions are not counted, because their wording varies from entry to entry and a count built on prose would measure the writing rather than the product.

How many of the 26 entries store a link a reader can open?

Verifiability is worth counting first, because a portfolio entry nobody can open is not evidence. Sixteen of the 26 entries store at least one URL, 62% of the portfolio. Counting by the link's domain, 12 store a web address, seven a Google Play listing and seven an Apple App Store listing. Those overlap, since one product can publish to all three surfaces, so they deliberately sum to more than 26.

Not every link is a production product. Three of the 12 web addresses are builds on vercel.app rather than production sites: Coffee Shop, Waitmate and Afriva. Nine entries link to a live app store listing: Food Magnet, Koor, CEDMAT, Three28, Pastel, Dooz, LoopedIn, TAL and Hear With You. Ten entries, 38%, store no link at all. Five of those are the builds with no client; the other five are Outstride, Augment Fit, JUJU, WOD Pro League and ConstrActive, which have no working public address today.

Which surfaces do the entries link to?

Grouping the same 26 entries by the surfaces they link to, rather than by link type, gives mutually exclusive buckets that sum cleanly to 26. No link at all is the largest group, at ten entries, 38%. Web-only is next at seven, 27%, and three of those seven are builds on vercel.app. Five entries, 19%, link to web, Google Play and the App Store together: Food Magnet, Pastel, Dooz, LoopedIn and TAL. Four reach a mobile store with no web surface: Koor and CEDMAT on Google Play only, Three28 and Hear With You on the App Store only.

Full three-surface presence is the exception in this portfolio, and a single web surface is the most common linked shape. That says what these 26 products publish today, not what the market builds, and a different 26 projects would redistribute every bucket.

Which technologies appear most often across the 26 entries?

Technology frequency is counted with one explicit rule: an entry counts once for a technology if that name appears in its tag list or among its declared tech stack items. Free-text descriptions are excluded. Under that rule Node.js and AWS tie at nine entries each, Firebase follows at eight and React.js at seven. One detail of the rule is worth stating: Food Magnet's declared stack items read "AWS Lambda Functions (Backend)" and "React.js (Admin Dashboard)", and a name counts wherever it appears inside an item, so Food Magnet counts for AWS. A count that accepted only the bare string "AWS" would give AWS eight.

These are the stacks of the products, not a record of DevoraX's own technology decisions. Twelve of the 26 were built inside other companies, where the stack was set within that company rather than chosen by DevoraX.

Why should the technology counts be read as a floor?

The technology table is a floor, not a census, and the entries show exactly why. Nineteen of the 26 declare exactly two tech stack items, typically one frontend and one backend. Only seven declare more, and one declares eight. A list that stops at two names cannot describe a stack that runs to a dozen dependencies.

The project descriptions show what falls through the gap: MongoDB on Bondly, Socket.io and Redis on WOD Pro League and LoopedIn, PostgreSQL through Supabase on Afriva, and Fluent-FFmpeg, BullMQ and S3 signed URLs on JUJU. MongoDB, Redis, Socket.io, PostgreSQL and S3 each score zero across all 26 tag and tech stack lists. Vercel hosts three of the web links and appears in none of them either. Read every line in the technology table as a minimum.

Does the portfolio favour React Native or Flutter?

Twelve of the 26 entries name a cross-platform mobile framework in their tags or declared stack: six React Native and six Flutter. The two sets do not overlap, and no entry names a native-only toolchain such as Swift, SwiftUI, Kotlin or Jetpack Compose. Of the six React Native entries, four link to a store listing; of the six Flutter entries, three do.

The split follows context more closely than preference. Four of the six Flutter entries are products Sameem worked on as an employee, at Zencloud or Webrange Solutions, and JUJU and Hear With You were direct client work. None of the six React Native entries was employer work: two were direct client work, two have no named client and two have no client. Within a sample this size an even split carries no statistical weight, and the portfolio cannot test whether framework choice relates to anything else. What it does support is narrower: across these twelve mobile builds the default was cross-platform.

What does the portfolio show about stack concentration?

Two concentrations stand out. First, backends: nine entries name Node.js and five name NestJS, with no overlap between the sets, so 14 of 26, 54%, name a Node-family backend. Second, managed backend services: eight name Firebase and two Supabase, again with no overlap, so 10 of 26, 38%, 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 26, 69%, touching the React ecosystem somewhere.

Container orchestration is the opposite story: Kubernetes appears in exactly one entry, the AI E-Commerce Ecosystem, which has no client and no public link. The category labels agree with the tags, with six entries labelled "Node.js Backend & AWS" and four labelled "React Native & Node.js".

What would make this portfolio more citable next time?

The most useful output of counting a portfolio is the list of things it should have captured. Four gaps are visible. No entry has a dedicated field for the context of the work, whether it was done as an employee, for a direct client or as a self-initiated build, so this article has had to add it by hand. No entry records when the work was done: the only date is the timestamp from when the entry was created, which dates the portfolio entry rather than the build. The tech stack list caps most entries at two items, which is why the technology counts are a floor. And links are not re-checked automatically, so a domain that lapses or changes hands keeps pointing somewhere else until someone notices. None of these is hard to fix at capture time, and all are hard to fix afterwards.

Limitations

• n=26 from one small studio's portfolio. These are the products one engineer has worked on across several employers and projects, not a random or representative sample of software projects.
• Context has no dedicated field in the data. Whether each entry was employer work or direct client work, has no named client or has no client, was added by hand for this article.
• The technology counts are a floor, not a census. 19 of the 26 entries cap their declared tech stack at two items, and the project descriptions name MongoDB, Redis, Socket.io, PostgreSQL and S3 on individual builds while those five score zero across all 26 tag and tech stack lists.
• Counts use structured fields only. Free-text descriptions were not counted, so a technology mentioned only in prose does not appear in any table.
• Links were counted as stored. A stored URL means a page is linked, not that it is a production system: 3 of the 12 web links are builds on vercel.app.
• The portfolio contains finished or showcased work only. There is no entry for cancelled, abandoned or failed work, so every pattern here is survivorship-limited.
• The only timestamp on any entry is its creation date, which dates the portfolio entry (8 in 2025, 18 in 2026) rather than the build.
• 23 of the 26 entries are flagged as featured, so this is a curated showcase rather than a complete list of everything Sameem has worked on.

What this data cannot answer

• Is React Native faster, cheaper or more maintainable than Flutter? The portfolio 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 6 Flutter entries, and 4 of the 6 Flutter entries employer projects against none of the React Native ones, the portfolio cannot support a correlation claim in either direction.
• Did any stack choice cause any business outcome? The portfolio holds no outcome data, no control group and no counterfactual.
• What did these builds cost, or how many developer hours did they take? No cost, effort or team-size data is stored in any entry.
• How long did each project run from kickoff to launch? The only date on an entry is its creation date, which dates the portfolio entry rather than the build.
• How do these figures compare to industry averages? n=26 from one portfolio cannot establish or test an industry baseline.
• Which technology choices failed, and why? Only finished or showcased work is in the portfolio, so there is no failure data to analyse.
• Who chose each stack? On the employer projects the decision sat inside another company, and no entry records who made it.