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.
