Independent product · Programmatic SEO · 2026 — Present
Designing a scalable decision platform for software and technology selection
I created OwnerLens as an end-to-end product: entity model, comparison experience, programmatic content system, rendering strategy and deployment economics.
Visit live product
CASE / 03 SYSTEM ONLINEIMAGE PLACEHOLDER · Replace through public/images/cases and the case-study data file.
01 · Executive summary
The shortest honest version.
Software research is fragmented across vendor pages, generic listicles and expensive consulting, while user questions are highly specific.
I designed a structured entity graph, reusable comparison templates and cost-aware static rendering for long-tail decision paths.
OwnerLens became a live, extensible platform for software comparisons, alternatives, calculators and technology-selection guidance.
02 · Context
Why the engineering work mattered.
OwnerLens helps founders, operators and specialists compare software and understand which tools fit a particular business context.
The product treats content as structured application data. Software, professions, industries and locations can combine into decision pages without hand-building every route.
03 · System design
A clear path from signal to production.
Structured software, role, industry and location records.
Reusable relations power comparisons and switching scenarios.
Build-time indexes make route generation deterministic.
Pages render according to value, freshness and cost.
Fast search-oriented pages and practical calculators.
Constraints that shaped the solution
- A large route surface had to fit within practical hosting limits.
- Generated pages still needed to answer a concrete user decision.
- Content updates and static-generation cost had to remain controlled.
- The system needed to evolve without a runtime database dependency for every page.
04 · Decision ledger
The trade-offs behind the implementation.
A large embedded runtime data file exceeded practical serverless limits.
More explicit build artifacts and generation workflows.
Runtime pages stayed leaner and easier to deploy.
The same software can answer many different decision contexts.
Higher modeling effort before page production.
New useful routes can reuse consistent structured knowledge.
Not every long-tail page deserves the same regeneration cadence.
More nuanced route and revalidation rules.
Infrastructure cost can follow page value and freshness needs.
05 · Change
Before and after.
BeforeIsolated software research pages
AfterConnected entity-driven decision paths
BeforeRuntime-heavy content access
AfterGenerated catalogs and page indexes
BeforeUniform regeneration strategy
AfterCost-aware SSG and ISR boundaries
BeforeGeneric software lists
AfterContext-specific comparisons and alternatives
06 · Outcomes
Technical change translated into team value.
- Built a live Next.js product around structured data and programmatic routes.
- Removed the need for a large runtime SQLite payload from the page-delivery path.
- Designed SSG and ISR behavior around scale, freshness and infrastructure cost.
- Owned decisions normally split across product, engineering, UX and SEO.
- Established a repeatable content architecture for continued expansion.
- Turned a broad research idea into a public, testable product.
07 · Evidence boundary
Precise claims build more trust than inflated ones.
- The product is publicly accessible at ownerlens.online.
- This case distinguishes current architecture from future scale targets.
- Product and technical decisions are direct founder-level responsibilities.
08 · Reflection
What the project changed in my engineering judgment.
Modeling user decisions as relations between entities created more leverage than publishing disconnected pages.
I would add stronger source provenance, freshness scoring and query-level feedback loops to the content system.
Product ownership, scalable content architecture and cost-aware Next.js engineering.