What Happens During an ERP Interface Layer Build: A Week-by-Week Guide
From discovery sprint to go-live. A week-by-week guide to what happens when you build an interface layer over your business system.
You have decided to build an interface layer. You have chosen to keep your existing ERP as your system of record and replace only the part your team interacts with every day. Good decision.
But now the question is: what actually happens next? How long does it take? What does each week look like? And what do you need to do on your side?
This guide answers those questions. It walks through a typical 10-week interface layer build from start to finish. Every project is different, but the structure below reflects what we have delivered for UK manufacturers and distributors running Business Central, OrderWise, Sage 200, SAP Business One, and other major ERP platforms.
If you want the headline upfront: a typical interface layer build takes 10 weeks from kick-off to go-live. That includes a discovery sprint on-site, architecture and design, core API integration, feature development, testing, and deployment. Post go-live, it becomes a managed subscription with ongoing hosting, monitoring, maintenance, and feature evolution.
Here is exactly what happens, week by week.
Week 1: Discovery Sprint (On-Site)
Week 1 happens at your site. Two to three Sysgraft engineers arrive on Monday morning and spend the week embedded with your team.
What we do:
- Observe real workflows. We watch how your sales team navigates the ERP to find order status. We see your warehouse staff export data to Excel. We identify the workflows that cause the most friction. The process document says one thing; reality is often different.
- Conduct stakeholder interviews. We speak with operations managers, warehouse leads, finance teams, customer service staff, and the IT team. Each role has a different relationship with the ERP and different pain points.
- API audit against your live tenant. We authenticate against your actual ERP instance and enumerate every available API endpoint. We test read operations against real data. We validate write-back against your business logic and permission structure.
- Map the adapter layer scope. We identify which entities need exposing through the adapter layer, what transformations are needed, and where caching or idempotency is required.
- Wireframe key screens. By Thursday we have rough wireframes of the new interface. We walk them past stakeholders to validate the direction before anyone writes a line of production code.
Output: A pain-point map, a live API audit report, wireframes and UX concepts, and a fixed-price build proposal. The proposal covers exactly what will be built, the timeline, and the cost. There is no scope ambiguity.
If your ERP does not expose a required endpoint through its standard API, we flag this during the sprint. Often the fix is a custom API page (or equivalent on your platform) that extends the standard API surface. We scope and quote this work separately before the main build begins.
Weeks 2–3: Architecture and Design
With the discovery sprint complete and the scope agreed, Weeks 2 and 3 focus on turning wireframes into a detailed blueprint.
Adapter layer design: The adapter layer is the critical piece. It sits between your ERP’s API and the new frontend, providing a clean interface that isolates the rest of the application from ERP-specific quirks. During these weeks we design:
- The adapter layer class structure and entity mapping
- Request/response transformation rules (ERP data models rarely map cleanly to what the frontend needs)
- Caching strategy (what gets cached, for how long, invalidation rules)
- Idempotency keys for write operations (preventing duplicate orders if a network call is retried)
- Error handling and fallback behaviour
Data mapping: Every ERP models data differently. A “customer” in your ERP might have a different field structure than what your customer portal needs to display. We map every field, every relationship, and every transformation. This is documented and signed off before build begins.
UX design: Wireframes from discovery become high-fidelity Figma designs. We design for each role: operations dashboard, warehouse pick list, customer portal, management KPI view. Designs are tested with real users from your team before development starts.
Tech stack finalisation: While the default stack is React, Next.js, and TypeScript with Node.js for the adapter layer, we confirm hosting (Azure UK South or AWS London), CI/CD pipeline, monitoring, and analytics tooling.
At the end of Week 3, you receive: the adapter layer specification, data mapping document, high-fidelity UI designs for all screens, the infrastructure architecture document, and a confirmed go-live target date.
Weeks 4–6: Core Build
Weeks 4 through 6 are the heaviest engineering period. The team builds the foundation that everything else sits on top of.
API integration and adapter layer: The ERP API client is built and tested against your live tenant. The adapter layer takes shape: entity mapping, caching, idempotency, error handling. Every call to your ERP is logged and monitored from day one.
Authentication: Staff authentication via Microsoft Entra ID SSO (or your existing identity provider) is implemented. Customer portal authentication is set up with secure, ERP-backed credentials. Role-based access control is configured at the application level, mapped back to your ERP’s existing permission structures where possible.
Caching layer: Redis or an equivalent in-memory cache is deployed. Frequently accessed data (item lists, customer records, price lists) is cached with configurable TTLs. Stale-while-revalidate patterns ensure the frontend never shows an empty state.
Frontend scaffolding: The Next.js project is initialised with the design system, component library, routing structure, and shared utilities. Server-side rendering is configured for performance. The build pipeline is set up with automated testing and deployment.
Weekly check-ins: Every Friday you receive a written progress report and a live demo of what was built that week. There are no surprises.
Weeks 7–8: Feature Build
With the core infrastructure solid, Weeks 7 and 8 are about building the features your team will actually use.
Dashboards: Each role gets its own dashboard. The operations dashboard shows live order status, stock alerts, and production tracking. The management dashboard shows revenue pipeline, stock health indicators, and operational KPIs. Real-time data, not batch-refreshed reports.
Portals: If a customer self-service portal is in scope, this is when it takes shape. Customers can log in, view order status, download invoices and statements, check stock availability and pricing, and submit enquiries. All data is live from your ERP via the adapter layer.
Workflows: Common operational workflows are reimagined in the new interface. Sales order entry, purchase order approval, inventory lookup, and pick list generation. Each workflow is designed to minimise clicks and eliminate the Excel workaround.
Role configuration: Permissions, default views, and notification preferences are configured per role. If your ERP already enforces certain permissions, we map those into the interface layer so nothing is bypassed.
By the end of Week 8, the application is feature-complete. Everything that was scoped in the discovery sprint exists and works against your real ERP data. No mock data. No sandbox. Live.
Week 9: Testing
Week 9 is testing week. Nothing goes live without passing every gate.
Integration testing: Every adapter layer endpoint is tested against your live ERP tenant. Read operations, write operations, error states, edge cases. If your ERP’s API rate-limits or returns unexpected data, we find it here.
User acceptance testing (UAT): Your team gets access to a staging environment running against your live ERP data. They test their actual workflows. They break things. We fix them. UAT runs for 3–4 days minimum, and the application does not go live until your team signs off.
Performance testing: Page load times, API response times, cache hit rates, concurrent user load. We benchmark everything against agreed thresholds. The threshold for page load is under 2 seconds. For API responses, under 300ms for cached data, under 800ms for live ERP reads.
Security review: Authentication flows are penetration-tested. Role-based access control is audited. Customer data isolation is verified. The OAuth 2.0 client credentials flow is checked for token leakage. We provide a security sign-off document.
If issues are found during testing, they are fixed and re-tested within the same week. The go-live date moves only if unresolved issues remain at the end of Week 9.
Week 10: Go-Live
Go-live week is structured and controlled. There are no all-nighters.
Deployment to UK infrastructure: The application is deployed to production infrastructure in UK-region cloud (Azure UK South or AWS London). SSL certificates, DNS, CDN configuration. The staging environment remains available for fallback.
Data verification: A final data check confirms the interface layer is showing correct data from your ERP. Customer records, orders, stock levels, pricing.
User rollout: We roll out by role, not all at once. Management dashboard goes live first. Then operations team. Then warehouse. Then customer portal. Each group gets a brief training session (30 minutes). If something goes wrong, only that group is affected.
Go-live support: Sysgraft engineers are available on Slack and phone throughout go-live week. Response time is under 2 hours during business hours. Critical issues are addressed immediately.
Go-live sign-off: You confirm the application is working to specification. Payment milestones are complete. IP is transferred. You own the code from day one.
Post Go-Live: Subscription
After go-live, the relationship moves to a monthly subscription. Here is what that covers:
Hosting and infrastructure: All hosting costs are included (compute, storage, CDN, caching). No surprise AWS bills. We monitor uptime, performance, and security.
Monitoring and alerting: Application performance monitoring (APM) tracks every request from browser to API to ERP. If the adapter layer fails to reach your ERP, we know before you do. Alerts go to Sysgraft engineers 24/7.
Security patching: Dependencies are updated monthly. Critical CVEs are patched within 72 hours. SSL certificates are auto-renewed.
Maintenance: Routine maintenance of the adapter layer, caching configuration, and infrastructure. If your ERP vendor releases an API update that affects the integration, we handle it.
Feature evolution: Minor enhancements and changes are included in the subscription (within reason). Major new features are scoped and priced separately. The 12-month minimum term gives both parties stability; after that it is 30 days’ notice from either side.
The subscription model is not a lock-in. You own the code. If you want to take the application in-house or move to another provider, the IP is yours and the architecture is documented.
What YOU Need to Do Each Week
An interface layer build is not a “throw it over the wall and come back in 10 weeks” engagement. Your team plays an active role. Here is what is expected, week by week:
| Week | What Sysgraft Does | What You Do | Estimated Time |
|---|---|---|---|
| Week 1 | On-site discovery, API audit, wireframes | Make stakeholders available for interviews; provide ERP access credentials; join wireframe walkthrough | 4–6 hours (spread across week) |
| Weeks 2–3 | Architecture, data mapping, UI design | Review data mapping; sign off UI designs; confirm infrastructure choices | 2–3 hours per week |
| Weeks 4–6 | Core build, API integration, auth, scaffolding | Review weekly progress demos; answer occasional questions about ERP behaviour | 1–2 hours per week |
| Weeks 7–8 | Feature build, dashboards, portals, workflows | Review feature demos; provide feedback on workflow design | 2–3 hours per week |
| Week 9 | Testing (integration, UAT, performance, security) | Assign UAT testers from your team; they test real workflows for 3–4 days; report issues | 4–6 hours per tester |
| Week 10 | Deployment, rollout, go-live support | Brief training sessions per role; final sign-off; communication to your team | 2–4 hours |
| Post go-live | Hosting, monitoring, maintenance | Nominate a primary contact for ongoing requests; report any issues via Slack | Minimal (ongoing) |
Your total time commitment across the entire 10-week build is roughly 20–30 hours, spread thinly. The heaviest weeks are Week 1 (discovery) and Week 9 (testing). The rest is mostly review and feedback.
What Can Go Wrong and How It Is Handled
No project plan survives contact with reality. Here are the most common risks and how we handle them:
The key principle is transparency. If something goes wrong, we tell you immediately. There are no hidden problems discovered the night before go-live. Weekly demos and written reports mean you always know the real status of the build.
Frequently Asked Questions
Q: Can the build be done in less than 10 weeks?
For a narrow scope, yes. A single-role dashboard with read-only data can be delivered in 4–6 weeks. A customer portal with read-only access can be done in 6–8 weeks. The 10-week timeline covers a full platform with staff dashboards, customer portal, and write-back workflows. We give you an exact timeline during the discovery sprint based on your specific scope.
Q: Will our team need extensive training?
No. The whole point of an interface layer is to make your ERP easier to use. The interface is designed around how your team actually works. Most users need a 30-minute walkthrough, not a day in a training room. The learning curve is measured in hours, not days.
Q: Does the build disrupt our existing ERP operations?
No. The interface layer reads and writes through the ERP's API. We do not modify your ERP instance, install extensions, or change your database schema. Your team can continue using the standard ERP interface throughout the build. There is no cut-over where the ERP becomes unavailable. The new interface runs alongside the existing one until you are ready to switch.
Q: What happens if we want to add features after go-live?
Minor enhancements are included in the subscription. Major new features (additional portals, complex new workflows, integration with third-party systems) are scoped and quoted separately. Because you own the code and the architecture is well-documented, adding features is straightforward. The adapter layer means new functionality rarely requires changes to your ERP.
Q: Can we cancel the subscription after 12 months?
Yes. The minimum term is 12 months, after which either party can cancel with 30 days' notice. You own the code. If you want to self-host after cancellation, we provide a handover package including deployment documentation and a support transition period.
Q: What ERPs does this work with?
Any ERP that exposes a REST API. We have delivered interfaces for Dynamics 365 Business Central, OrderWise, Sage 200, SAP Business One, NetSuite, and Epicor. If your ERP has a REST API, we can build an interface layer over it. The discovery sprint includes a live API audit that confirms what is possible before any build commitment.
Deciding If Now Is the Right Time
The right time to build an interface layer is when the cost of doing nothing is becoming visible in your operations. That might be your sales team spending three hours a day exporting data to Excel. It might be customers complaining about slow order status updates. It might be your management team making decisions on stale reports.
The wrong time is when you are mid-ERP replacement, mid-restructuring, or mid-acquisition. The interface layer needs a stable ERP environment to integrate with. If your system of record is about to change, wait until the new one is settled.
If you are not in the middle of an ERP upheaval, the window is now. The build takes 10 weeks. The disruption is minimal. The benefit starts on day one of go-live.
Ready to start your interface layer build?
The first step is a discovery sprint. Two to three days on-site. Live API audit. Fixed-price proposal. Valuable whether you proceed to build or not.
Book a Discovery Call