I'm a project manager planning a new digital commerce platform and would appreciate practical advice on both the technology direction and initial staffing. The business would begin small but could grow quickly, and products would be delivered electronically rather than shipped.
The main priority is accurate, complete product information and matching products to customers' specific requirements—not necessarily maximum response speed. Products may have many attributes and variants. AI would help research and populate product details, while people would review, correct, and maintain that information.
The system may eventually include accounts and permissions, customers whose searches and selections are tracked, sellers and brands with different sponsorship levels, product catalogs with detailed attributes, customer ratings and comments, sponsored placement, faceted product search, property-based sorting, product recommendations and purchases, contextual transactional email, advertising, and seller dashboards.
The technology options I'm currently considering are AWS with RDS or Google Cloud with Cloud SQL; PostgreSQL as the primary database; PostgreSQL trigram indexes initially, followed by Elasticsearch or OpenSearch if more advanced faceted search is needed; Node.js with TypeScript using NestJS or Express, or possibly Go; and a Next.js/React frontend with TypeScript and Tailwind CSS. I'm also evaluating how AI should be used for catalog research, normalization, and quality control.
I'm especially interested in whether an Entity-Attribute-Value database design is appropriate for products with many varying properties. I've also considered PostgreSQL JSONB and a more conventional relational model, so practical experience with the tradeoffs would be useful.
For staffing, I previously used a senior full-stack developer with strong database and backend skills as the technical lead, supported by a part-time frontend consultant and additional security and QA help. Would that be a sensible starting structure here—hiring a senior, backend-oriented full-stack developer who can choose and guide specialists as needed? Or would it be better to begin with a frontend or platform architect to establish a foundation for future scale?
I'm trying to avoid overengineering the first release while still making sound decisions around search, SEO, payments, catalog management, security, observability, email, and future growth. What architecture and first-hire strategy would you recommend?
5 Answers
Start by finding a genuinely strong senior full-stack developer with a backend and database bias, rather than choosing technologies first. Someone comfortable with AI-assisted development can often cover a lot of frontend work early on, while still making sensible decisions about data modeling, APIs, security, and infrastructure. The exact framework matters less than the lead developer’s judgment and familiarity with the stack.
The candidate matters more than getting the cheapest quote or hiring a large agency. Look for someone you trust who can own the technical direction and recognize when specialist help is actually needed.
Be cautious about using EAV as the default product model. It can appear flexible at first, but joins, filtering, reporting, validation, and indexing become difficult as the catalog grows. A conventional relational schema for stable fields, combined with carefully structured JSONB for genuinely variable attributes, is often easier to maintain. You can also define an attribute catalog with types, allowed values, aliases, and validation rules so that JSONB does not turn into an uncontrolled collection of inconsistent labels.
The important thing is to model the attributes around the searches and reports you actually need, rather than letting an AI-generated schema dictate the design.
That helps clarify the distinction. My concern with JSONB was inconsistent values that mean the same thing, but it sounds like a controlled attribute definition and normalization layer can address that without taking on the complexity of EAV.
Don’t overlook SEO when designing the search and filter system. Every combination of facets can accidentally become a crawlable URL, creating thousands of thin or duplicate pages. Decide early which pages should be indexable—typically selected category or brand pages—and keep most arbitrary filter combinations out of search indexes. This is also a useful screening topic for the first technical hire, since fixing an SEO-unfriendly catalog structure after launch can be painful.
The proposed technologies are reasonable, but the architecture needs to cover more than the framework list. A senior full-stack lead plus part-time design/frontend help is a sensible start, followed by a second full-stack engineer once operations and feature work increase. Plan for QA and security early, and remember that monitoring, vulnerability patches, deployment workflows, backups, scaling, and incident response consume real time even with a small system.
For the public catalog, use server-side rendering and a deliberate caching strategy in Next.js so search engines can index dynamic product pages. Keep the customer and seller portals in mind as a separate concern: they may eventually have different performance, security, and deployment needs from the SEO-focused storefront, even if they share the same domain.
Before committing to an MVP, map out payment flows, refunds, fraud handling, access to discontinued digital products, catalog editing and versioning, order failures, transactional versus marketing email, analytics, observability, and third-party integrations. Digital delivery removes shipping complexity, but it does not remove operational complexity. A short planning engagement with someone who has built a similar platform could prevent expensive redesigns later.
Before building a custom commerce platform, verify whether an existing product such as Shopify, WooCommerce, or a specialized digital-commerce service can cover the transactional pieces. A custom catalog and matching layer might still be justified if the product attributes and recommendation workflow are unusual, but payments, accounts, email, order records, and digital fulfillment may be cheaper and safer to integrate than to recreate. Starting with proven services can let the team focus its limited budget on the parts that actually differentiate the business.
That reinforces my inclination to begin with a backend-oriented full-stack lead. I’ve seen both excellent and poor results from staffing agencies and inexperienced developers, so finding the right person and assessing their judgment will be my main priority.