How We Build Custom ERPs in 4-12 Weeks
There's a dirty secret in enterprise software development. The timeline you get quoted, 6 to 12 months for a custom ERP, is not a reflection of how long the work actually takes. It's a reflection of how the industry is structured: layers of project managers, requirements documents that take weeks to write, design committees, and developers who context-switch between five projects.
We don't work that way. At Wind Growth, we ship production-grade ERPs in 3 to 12 weeks. Not MVPs. Not prototypes. Production systems handling real money, real compliance requirements, and real users every day.
The key difference: we operate as Forward Deployed AI Engineers. One person who understands your business deeply, armed with AI tools, doing the work of an entire traditional team.
The Traditional Agency Timeline Problem
Let me break down what a typical agency quote looks like for a custom ERP:
Traditional Agency Timeline
- 01Weeks 1-4: Discovery and requirements gathering
- 02Weeks 5-8: UX design and architecture
- 03Weeks 9-12: Design review cycles
- 04Weeks 13-30: Development sprints
- 05Weeks 31-36: QA and bug fixing
- 06Weeks 37-42: UAT and revisions
- 07Weeks 43-48: Deployment and training
Wind Growth Timeline
- 01Domain immersion and architecture
- 02Core data model and auth
- 03Iterative feature build
- 04Polish, testing, and deploy
- 05Ongoing iteration based on real usage
That traditional timeline adds up to $150K-$500K depending on where you hire. And here's what nobody tells you: most of that time isn't productive work. It's waiting. Waiting for sign-offs, waiting for the next sprint planning, waiting for the designer to hand off screens, waiting for the backend team to finish the API so the frontend team can start.
The bottleneck in traditional software development is not the coding. It's the coordination overhead between humans who each hold a fraction of the context. When one person holds all the context and uses AI to execute at machine speed, the coordination cost drops to near zero.
What is a Forward Deployed AI Engineer?
The term "Forward Deployed Engineer" originated at companies like Palantir, where engineers embed directly with clients to solve their specific problems rather than building generic products from an office. They learn the client's domain, sit in their operations, and build exactly what's needed.
We've been doing this for 5 years, long before it had a trendy name. The difference now is AI. A Forward Deployed AI Engineer combines that deep domain embedding with AI-assisted development tools that multiply output by an order of magnitude.
Here's what this actually means in practice: the hard part of building an ERP is not writing code. The hard part is understanding the business logic. What are the real rules? What are the edge cases nobody documented? What does the team actually do versus what they say they do? How does the data flow through the organization?
That's the work that matters, and it's the work AI can't do. AI can write a database migration in seconds, but it can't sit with your operations team and figure out that invoices from Quebec contractors come in 14 different formats and need to be routed based on rules that exist only in the accountant's head.
The real challenge in building custom ERPs is never the code. It's understanding the domain deeply enough to model it correctly. That's what we've spent 5 years and 105+ clients getting good at. AI handles the implementation. We handle the thinking.
Once the domain is understood, AI tools accelerate the build dramatically. I make the architectural decisions, define the data model, specify the business rules, and iterate through the logic. AI handles the mechanical implementation: scaffolding components, writing repetitive patterns, generating test coverage. The process is iterative, not a single pass. Every feature goes through rounds of logic review, architecture decisions, and refinement before it's done.
This is not about AI replacing developers. It's about one engineer who deeply understands your business using AI to move at a speed that was previously impossible.
Our Actual Workflow
Here's exactly how we build a custom ERP from first conversation to production deployment.
Phase 1: Domain Immersion (3-7 Days)
This is the part most agencies skip or rush through, and it's the most important phase. Before I write a single line of code, I need to understand your business the way you understand it.
I spend the first week doing nothing but learning your domain. I read your industry's regulations. I study your existing workflows: the spreadsheets, the manual processes, the workarounds you've built. I interview your team about edge cases and exceptions. I map out the entities, relationships, and business rules.
For DDV Fleet, this meant learning Belgian automotive tax law: BIV registration tax, annual road tax calculations, 21% VAT rules for different vehicle categories. For Koncret, it meant understanding Quebec construction law: RBQ licensing, CCQ and CNESST requirements, the legal mechanics of denonciations and quittances under the Quebec civil code. For Nomi Pass, it meant understanding BOGO deal economics across three Baltic countries with different VAT rates and consumer protection laws.
Domain immersion is not optional. The number one reason enterprise software projects fail is not technical. It's that the developers never truly understood the business they were building for. Every shortcut here creates exponentially more work later.
This phase produces a living document: the domain model. Every entity, every relationship, every business rule, every validation constraint. This document becomes the source of truth that guides the entire build.
Phase 2: Architecture and Core (3-5 Days)
With the domain model locked in, I architect the system. This is where experience across 105+ clients pays off. I've seen enough operational systems to know which patterns work and which create technical debt.
The stack is consistent across projects: Next.js with App Router for the frontend, Supabase (PostgreSQL) for the database with Row Level Security, TypeScript in strict mode everywhere. This consistency means every new project benefits from the accumulated context and proven patterns of previous ones.
In this phase, I build the foundation: database schema with migrations, authentication and role-based access control, the core data model with CRUD operations, and the basic navigation structure. The goal is to get a working skeleton up early so we can validate the architecture with real data before building out features.
Phase 3: Feature Build (2-6 Weeks)
This is where AI-assisted development changes the game entirely.
In a traditional project, each feature goes through design, specification, development, code review, QA, and sign-off. That cycle takes 1-2 weeks per feature, minimum.
With AI pair programming, the cycle compresses dramatically. I describe the feature with business context, the AI implements it across the full stack, I review and adjust, and we move on to the next one. What used to take a full sprint can often be done in a fraction of the time.
And here's what those numbers don't show: these aren't 77,000 lines of hastily generated code. Nomi Pass has 2,310 Jest unit tests and 18 Maestro E2E test flows. Koncret App has 100 test files. DDV Fleet has comprehensive validation for every Belgian tax calculation. The code is production-grade because tests are written alongside features, and I enforce quality standards at every step.
Phase 4: Polish, Test, Deploy (1-2 Weeks)
The final phase is integration testing, performance optimization, deployment configuration, and user training. Because we keep clients in the loop throughout the build with regular check-ins and progress updates, the final review stage is smoother. There are fewer surprises because feedback has been incorporated along the way, not saved for the end.
Why Speed Doesn't Mean Low Quality
I get this pushback constantly: "If you're building that fast, you must be cutting corners."
The opposite is true. Speed means more iterations, not fewer.
Traditional: 2 Iterations in 6 Months
- 01Build the spec as written
- 02Discover it doesn't match reality at UAT
- 03Rework under budget pressure
- 04Ship something that kind of works
Our Approach: Rapid Iterations
- 01Build first version of a feature quickly
- 02Get client feedback on real functionality
- 03Adjust based on what they actually need
- 04Repeat until it fits their workflow
- 05Move on to the next feature
When a feature takes weeks to build, nobody wants to throw it away and start over. When you can build faster, you can afford to iterate. Try something, get feedback, adjust. The final product is better because it's been through more real-world feedback cycles, not because anyone got it perfect on the first try.
Take Koncret's AI document pipeline as an example. The first version used simple keyword matching to classify incoming documents. After testing with real construction invoices and denonciations, we discovered that Quebec contractors format these documents in wildly inconsistent ways. So we iterated, adding heuristic classification, then Gemini AI classification, then a multi-strategy matching system that combines both. That kind of iterative refinement would have blown any traditional project's budget. For us, it was Tuesday.
The Domain Learning Advantage
Something people don't expect: building across completely unrelated industries has made us faster at each new one. We've been doing this for 5 years, across 105+ clients, long before "Forward Deployed AI Engineer" became a buzzword in tech. The methodology of embedding in a client's business, learning their domain from scratch, and building exactly what they need is not new to us. AI just made us dramatically faster at the building part.
Belgian automotive fleet management, Baltic hospitality subscriptions, and Quebec construction coordination have almost nothing in common on the surface. But the underlying patterns (entity lifecycle management, compliance rule engines, multi-role access control, financial calculations with tax logic, document processing pipelines) repeat everywhere.
Every ERP is fundamentally the same problem: model the domain accurately, enforce the business rules consistently, and surface the right information to the right person at the right time. The domain changes. The engineering patterns don't.
When I start learning a new industry, I'm not starting from zero. I'm pattern-matching against 5 years of client engagements and multiple production ERPs worth of architectural decisions. The domain immersion phase is about learning the unique vocabulary and rules of your industry, not figuring out how to structure the software.
Been told your business is "too niche" for custom software? That's exactly where we excel.
What This Means For You
If you're running a business on spreadsheets, disconnected tools, and manual processes, you probably think you have two options: buy an off-the-shelf tool that covers 70% of what you need (and jury-rig the rest), or spend $200K and a year building something custom.
There's a third option now. AI-assisted development has compressed the timeline and cost to the point where a custom ERP, built exactly for your domain, your workflow, your compliance requirements, is within reach for businesses that never could have justified it before.
The math has changed. If you're spending 15+ hours a week on manual processes (our average client was before we built their system), and a custom ERP costs a fraction of what it used to, the ROI timeline is measured in months, not years.
If you're curious whether your business is a fit for this approach, we do free strategy calls where I'll learn about your operations and tell you honestly whether a custom build makes sense or whether an off-the-shelf tool would serve you better. No pitch deck, no sales team, just a conversation about your business.
Book a free strategy call and let's figure out what your business actually needs.
