I’m looking for an independent technical review of an MVP architecture and a developer’s proposed change in direction.
This is not intended to become a conventional equipment-listing website. The initial product is Equip-Ex, a marketplace and transaction-intake layer for industrial equipment. Over time, the same underlying system is intended to support broader infrastructure opportunity routing through Power-Ex / Energy Exchange.
The operating principle is:
Thin public-facing applications connected to a shared, durable operational spine.
Proposed MVP stack:
• WordPress for the public website, content management, SEO, landing pages, knowledge base, and initial marketplace/directory functions
• GeoDirectory and potentially WooCommerce for mature listing, account, search, and transaction functionality
• Base44 for rapid prototypes, workflow validation, and selected internal interfaces
• Zoho CRM and Zoho Inventory as operational systems of record
• Zoho Creator where specialized operational applications are required
• n8n as the orchestration layer connecting forms, websites, CRM, inventory, communications, enrichment, and external services
• Cloudflare for domains, DNS, security, routing, and related infrastructure
• Google Workspace for business identity and communications
• Instantly for the separate outbound-email operation
• APIs and webhooks used to prevent the website from becoming the system of record
The initial MVP does not need to be the final version of the entire platform. It needs to:
- Publish equipment and opportunity listings
- Capture seller, buyer, project, site, and partner inquiries
- Route each submission into the correct workflow
- Create or update the appropriate CRM records
- support controlled document and image handling
- Track opportunity status and ownership
- Produce a credible public-facing experience
- Remain understandable and maintainable by future developers
- Generate commercial activity before the larger platform is built
The developer moved toward a custom Next.js implementation and characterized WordPress as legacy. My concern is not that Next.js is inherently wrong. My concern is that the architectural change appears to replace a deliberately modular MVP with a custom application before the business workflows have been proven.
A custom Next.js system may require us to build or select replacements for:
• Content management
• Administrative interfaces
• Listings and directory management
• User accounts and permissions
• Search and filtering
• Form management
• Media handling
• SEO controls
• Marketplace functions
• Plugin-provided capabilities
• CRM and inventory synchronization
• Documentation and nondeveloper administration
I have not yet seen a clear architecture decision record showing:
• Which verified requirement WordPress cannot satisfy
• Which component Next.js is replacing
• The expected difference in development time and cost
• The ongoing maintenance burden
• The proposed source of truth for each data object
• How n8n, Zoho, Cloudflare, Workspace, and Instantly fit into the new architecture
• What portion of the system becomes dependent on the original developer
• What measurable MVP outcome becomes easier or faster
I am not looking for “WordPress good” or “Next.js good” answers.
I would appreciate opinions on these questions:
- Does the modular stack make sense for an early commercial MVP?
- What concrete requirements would justify moving the public application to Next.js now?
- Would you use WordPress as the public shell while keeping Zoho as the operational source of truth?
- Is n8n appropriate as the integration and orchestration layer at this stage?
- Which architectural documents should a developer provide before changing the agreed stack?
- What acceptance tests would you require before approving the build?
- Is the proposed custom architecture solving a demonstrated limitation, or introducing premature complexity?
I’m especially interested in responses from developers who have built marketplaces, directories, CRM-connected platforms, or systems that began as modular MVPs and were later hardened into custom applications.
Top comments (1)
I can offer some insight as someone who has worked with different types of software architectures throughout my professional career. I’ve had to make similar decisions around whether it makes sense to build and own a component yourself or rely on a third-party service.
Like most architecture decisions, there’s a balance.
In your case, the modular stack makes sense if the goal of the MVP is to move quickly, validate the workflows, and determine whether there is real commercial demand before investing heavily in custom software. You’re effectively buying a lot of mature functionality instead of building it yourself.
That comes with tradeoffs, though. You now have several components and integration boundaries to maintain, less control over some parts of the system, and potentially more complexity as business logic starts spreading across WordPress, plugins, Zoho, n8n, and other services.
There can be good reasons to move toward a custom stack, but I think the developer needs to demonstrate what specific problem that change is solving.
For me, I’d want to see a real architectural pain point around scalability, reliability, cost, security, maintainability, or product requirements before taking on the additional custom ownership. A specific limitation of the modular MVP should be articulated in the ADR, along with why solving that limitation is worth the additional development and maintenance cost.
Sometimes it absolutely is worth it.
For example, the marketplace workflow may become much more domain-specific over time. Listings may stop being relatively conventional “title, description, photos, price, contact” records and start requiring custom schemas, relationships between equipment, projects, sites, buyers and sellers, specialized permissions, transaction states, or business rules that become difficult to express cleanly through plugins and n8n workflows.
At that point, owning more of the application and domain model could actually simplify the architecture rather than complicate it.
But based on what you’ve described, I’d want the developer to clearly demonstrate that you’ve reached that point. “WordPress is legacy” by itself isn’t an architectural reason to make the switch.