I'm a project manager planning a new digital-commerce site and would appreciate practical guidance on both the technical foundation and initial staffing. The business would begin relatively small but could grow quickly. Products would be delivered electronically, so there is no physical shipping or supply-chain component.
The main priority is accurate, complete product information and matching products to very specific customer requirements, rather than optimizing purely for raw response speed. Products may have many attributes and variants. AI would help research and populate product details, while humans would review, correct, and maintain the data.
The system may need accounts, different customer access levels, customer selections and recommendations, sellers and brands, sponsorship and advertising levels, product catalogs, detailed attributes, ratings and reviews, search, faceted filtering, sorting by product qualities, purchasing, dynamic transactional email, advertising placements, and seller dashboards.
The initial architecture I'm considering is AWS with RDS or Google Cloud with Cloud SQL; PostgreSQL as the primary database; PostgreSQL trigram indexes initially, with OpenSearch or Elasticsearch if the catalog eventually requires more advanced faceted search; Node.js and TypeScript with NestJS or Express, or possibly Go, for the backend; and Next.js, React, TypeScript, and Tailwind CSS for the frontend.
I'm especially interested in whether an EAV schema is appropriate for the detailed product attributes, or whether a conventional relational design combined with PostgreSQL JSONB would be more maintainable. I'd also appreciate advice on the first technical hire. Would a senior, backend-oriented full-stack developer make the best lead, supported by part-time frontend, design, QA, security, or infrastructure specialists? Or would it be better to begin with a frontend or architecture specialist who can establish a foundation for future growth?
4 Answers
Be cautious with EAV. It looks flexible, but attribute-heavy joins and generic value columns become difficult to query, validate, index, report on, and maintain as the catalog grows. A structured relational model is usually better for attributes that are important to filtering and reporting. PostgreSQL JSONB can work well for less predictable or category-specific data, provided you define a controlled vocabulary, validation rules, and normalization for equivalent values. The key is a clear data model and governance process, not simply choosing EAV or JSONB.
Your filter design also affects search-engine visibility. If every possible filter combination creates an indexable URL, you can end up with thousands of nearly identical pages and weak search performance. Decide early which pages deserve indexing—typically categories and selected brand or product pages—and keep most arbitrary filter combinations out of search indexes. This is worth discussing with the first backend hire because it affects URL structure, server rendering, canonicalization, and caching from the beginning.
Before building a custom commerce system, check whether an existing platform can handle the transactional pieces. A hosted or established commerce product might cover accounts, payments, orders, email, and seller administration while you build only the differentiated catalog, attribute matching, and recommendation experience. If custom development is necessary, start with a senior full-stack lead and add a frontend/design or product specialist part-time. Once the system is live, plan for a second engineer because monitoring, security patches, deployment workflows, incident response, and infrastructure maintenance will otherwise consume the lead’s feature-development time.
Separate concerns where it helps: the public catalog needs server-side rendering, strong SEO, and careful caching, while customer and seller portals may prioritize authenticated interactions and responsiveness. Also design payment failures, refunds, fraud, access to discontinued digital products, catalog versioning, order history, email separation, analytics, and observability into the plan. A short architecture and MVP-planning engagement with someone experienced in digital commerce could prevent expensive omissions.
Start by finding one excellent senior full-stack engineer with a strong backend and database background. They should be comfortable making pragmatic technology choices and using AI as a productivity tool, but the specific framework matters less than their judgment and ability to own the system. A capable lead can help determine whether you need contractors for design, frontend work, QA, or security. Spend more time evaluating trust, communication, and relevant experience than comparing an endless list of technologies.
That supports my initial instinct to prioritize a backend-focused full-stack lead. I’ll be careful about fit, since I’ve seen both unsuitable contractors and inexperienced developers produce more problems than progress.
The concern with JSONB is that different entries could represent the same property or value. Would schema validation, controlled attribute definitions, and normalization address that problem without requiring EAV?