How to build an ERP app without code: a step-by-step guide

ERP app development without code is an eight-step job that non-developers can finish on a no-code or low-code platform such as Appsmith, Retool, Microsoft Power Apps, Budibase, ToolJet or Airtable. The steps are: map processes, choose a platform, set up the data model, migrate data, build screens, configure roles, test with real transactions, then launch and train. The result is a working internal ERP app. Inventory, purchasing and approvals run on one database that the team owns.

What an ERP app needs to do for your business

An ERP app runs core business processes on one shared set of data. Gartner defines ERP as tools that “share a common process and data model” across finance, HR, distribution, manufacturing, service and the supply chain. Oracle states the design principle directly: “ERP systems are designed around a single, defined data structure (schema) that typically has a common database.”

SAP’s definition lists finance, HR, manufacturing, supply chain, sales and procurement as the processes ERP covers. TechTarget adds inventory management and purchasing, and notes that companies that make or distribute physical goods “need additional ERP modules, typically for inventory management and supply chain management.”

Treat the shared database as the test for any no-code build. If purchasing, inventory and accounting each keep their own spreadsheet, the result is a set of disconnected apps, and calling it an ERP does not change that.

Build or buy: when a no-code ERP makes sense

Oracle, SAP, Intuit, CSI Software and Microsoft were the top five ERP vendors by 2025 ERP applications revenue in Apps Run The World’s August 2026 ranking. The same report says the market grew 11% to top $151 billion in 2025. Here are the five vendors with their revenue figures:

Packaged ERP gives you accounting standards, audit features and upgrades that a vendor maintains. The trade-off is fit. Gartner notes that “No single ERP suite vendor has best-in-class capabilities in all areas,” and that buyers “may need to make compromises when standardizing on a suite.” Gartner also warns that ERP scope “that is highly customized based on current or near-term requirements will fail to keep up with changing business goals after implementation.”

These criteria separate a no-code build from a packaged purchase:

Use one rule. Build the operational layer without code when the ledger can stay in an accounting system you already trust. Buy packaged ERP when the system must be the book of record for financial reporting.

What you need before you start

A named process owner for each module is the first prerequisite. Panorama Consulting recommends designating data owners for each functional area and making them responsible for keeping their data free of inaccuracies and duplicates.

Collect these items before anyone opens a builder:

• Process owner: One person per module who can decide how purchasing or inventory should work and sign off on test results.
• Documented workflows: A written description of each step, who performs it, and what triggers the next step.
• Data inventory: A list of every source, including spreadsheets, a legacy ERP, accounting software and the e-commerce or CRM tools that hold orders and customers.
• Budget: Platform fees, any premium connector licences, and the internal hours of the people building and testing.
• Test group: Five to ten people who do the work daily and will run real transactions during the pilot.

Microsoft’s Dynamics 365 guidance points out that a legacy system can be another business application or a collection of Excel spreadsheets, and that only relevant and useful data should move. Mark every spreadsheet in the inventory as migrate, archive or retire before Step 1.

How to build an ERP app without code: step by step

Map processes and pick one module first, choose a platform that fits your data and permission needs, design a clean data model, then migrate and validate data and connect existing systems. Build screens and approval flows per role, lock down roles and turn on audit logs, test with real transactions and reconcile against the old system, then launch in phases, train users and assign owners for maintenance.

Step 1: Map your processes and pick your first modules

Start with inventory or purchasing. Both have clear records (items, suppliers, orders), measurable outcomes and a natural approval step. Draw the current process end to end: who requests stock, who approves, who receives goods, who pays.

Building every module at once is the main mistake here. Panorama’s 2026 report release quotes Chris Devault: “Organizations often discover fatal misfits late in the project, so they turn to additional technology, scope expansion, and custom builds.”

Write down the three to five reports the first module must produce, such as stock on hand, open purchase orders and items below reorder point. Those reports define what the data model in Step 3 needs.

Step 2: Choose a no-code or low-code platform

Viktor, Appsmith, Retool, Microsoft Power Apps, Budibase, ToolJet and Airtable are options for an ERP build. Viktor is the one option here that builds the app from a description: he writes, deploys and hosts small internal apps from a plain-language request in Slack or Microsoft Teams, while the other six give a visual builder that someone on the team operates. Third-party pricing checked November 2026.

Two licensing details change total cost. In Power Apps, an app that uses at least one premium connector, a custom connector or an on-premises gateway requires a per app or per user plan for every end user. Microsoft also states the Power Apps per app SKU is no longer available for purchase by new customers from January 2, 2026.

Pick a platform whose audit logs and custom roles fit your full user count and control requirements.

Step 3: Set up your data model

A clean schema has one table per real-world thing: items, suppliers, locations, purchase orders, purchase order lines, stock movements and users. Each table gets a unique ID, and relationships link by ID (a purchase order line points to one item and one purchase order). Avoid linking by matching names.

Airtable’s inventory tracker template lists the item fields most teams need: item name, SKU, category, quantity on hand, reorder point and minimum stock, location, supplier info, and cost per unit and total value. Use that list as a checklist for the items table.

Copying the spreadsheet structure is the common failure. A spreadsheet often stores supplier names in a text column, repeats them with spelling variants, and keeps stock as a single number that someone overwrites. In a proper model, quantity on hand comes from a stock movements table (receipts minus issues), which gives every change a record.

Before moving on, draw the schema and check that each report from Step 1 can be produced from it with joins alone.

Step 4: Migrate data and connect existing systems

Clean data before it moves. Common cleanup targets in SAP S/4HANA migrations include duplicate customers and vendors, missing mandatory fields such as tax and bank details, and vendors that also act as customers. The same issues show up in spreadsheets. Panorama Consulting cites its 2019 ERP Report, in which 41% of respondents said data issues caused their project to run over schedule.

Run the migration in this order:

1. Extract and freeze: Export each source once and stop edits to that copy.
2. Deduplicate: Merge duplicate suppliers and items, then pick one surviving record and keep a map of old IDs to new IDs.
3. Map fields: Match each source column to a target field and confirm formats. Oracle’s load templates, for example, require dates in YYYY/MM/DD format and a period as the only decimal separator.
4. Load master data first: Load suppliers, items and locations before open purchase orders and stock balances.
5. Validate: Compare record counts and totals between source and target.

Microsoft recommends a full migration about a month before go-live followed by weekly delta loads. This lets business users compare source and target systems before cutover.

For live connections, Appsmith, Retool and Budibase support REST API connections. Panorama advises adding a reconciliation checkpoint that compares record counts and field values after each synchronization cycle. Build that check into every sync before go-live.

Step 5: Build screens and workflows with drag-and-drop widgets

Each role gets its own screen. A buyer needs a purchase order form and a list of items below reorder point. A warehouse lead needs a receiving screen. A manager needs an approval queue and a dashboard of open orders and spend.

The standard building blocks are tables (lists of records with filters), forms (create and edit), dashboards (charts and totals) and approval flows (status changes triggered by a button). ToolJet’s inventory template covers the core flow: create products, record receipts and issues, reconcile stock counts, and track replenishment from request through receipt.

Plan for platform query limits while building. Power Apps retrieves only the first 500 records from a data source by default, adjustable to a maximum of 10,000 for queries it cannot delegate. Appsmith handles query responses of up to 5 MB and recommends server-side pagination.

Each screen is done when the person in that role can finish their daily task without opening a spreadsheet.

Step 6: Configure roles, permissions and audit trail

Set permissions per module before any real user logs in. The principle comes from internal control standards. GAO’s federal internal control standards separate responsibilities for authorizing transactions, recording them, reviewing them and handling the related assets, so no single person controls a whole transaction.

Platform features differ:

• Appsmith: Granular access control covers applications, workspaces and queries. The audit log records what activity occurred, who performed it and when, and exports as JSON.
• Retool: Retool logs user actions such as query runs and password resets. Cloud logs are retained for one year, and streaming to Datadog or Splunk is Enterprise-only.
• Power Apps and Dataverse: Dataverse auditing answers who created or updated a record, which fields changed and the previous value. Microsoft notes that exporting audit logs isn’t currently supported, so retrieval runs through the Web API or SDK.

Approval steps belong in the same configuration. Approvers should see only the queue for their threshold, and the person who created a purchase order should not be able to approve it.

Turn on audit logging on day one. A log switched on after go-live has no record of the migration or the first weeks of use.

Step 7: Test with real transactions

Run the pilot with real purchase orders, real receipts and real supplier data from the last month. Fake data hides the problems that matter: supplier names with odd characters, partial deliveries, returns, orders that span two approval thresholds, and items with no reorder point set.

Reconcile against the old system before go-live. Microsoft’s Dynamics 365 guidance calls for a mock cutover of all open balances and open transactions, with migrated balances agreeing with the legacy systems. SAP’s migration cockpit includes a simulation step that tests the migration without posting data.

A payroll rollout shows the cost of skipping this step. Panorama’s Navajo Nation case estimated that withholding variances touched 10 to 15 percent of payroll records in the first affected pay period. Panorama’s recommendation is to reconcile converted records against the legacy system before go-live.

Set the go-live gate as zero unexplained differences in stock on hand and open purchase order value between the old system and the new app.

Step 8: Launch, train your team and maintain

Roll out in phases: one site or one team first, then the rest. Panorama’s 2021 ERP Report says a phased approach is less risky organizationally because users have more time to learn and adapt to the new system, though it takes longer than big bang.

ERP is hard to learn at first, and training changes how long that lasts. In Prosci’s 2025 Unlocking ERP Implementations study, training led all recommendations for improving value realization in its people and change management category.

Published research does not give a measured time to proficiency. An Emerald article cites Caldwell (1998) for an initial three to nine months productivity dip after ERP go-live.

Maintenance needs named owners:

• App owner: Approves changes to screens, fields and workflows, and tests them in a copy before publishing.
• Data owner: Checks duplicates and reconciliation exceptions weekly.
• Backup owner: Confirms backups run and that a restore works. PCAOB staff guidance on user-developed applications includes reviewing the procedures for backing up the applications and data.

Keep the old spreadsheets read-only until the new app has passed at least one month-end. Microsoft’s Azure Storage migration guidance recommends retaining source data in a read-only state as a fallback until the target is confirmed complete and correct.

Worked example: an inventory and purchase-order module

This walkthrough is an illustration, not a benchmark. Replace each placeholder with your own operating numbers: daily demand, supplier lead times and the approval limits your finance lead sets.

1. Input: Item, supplier and location records from Step 4. Action: Create an items table with SKU, supplier ID, location ID, reorder point and safety stock fields. Output: One row per SKU, linked by ID to its supplier.
2. Input: Receipts and issues. Action: Record each as a row in a stock movements table with item ID, quantity, type, user and timestamp. Output: Quantity on hand calculated as receipts minus issues for each item and location.
3. Input: Your average daily demand and supplier lead time per item. Action: Calculate the reorder point. ASCM gives the formula as “Order point = DDRP + DDLT + Safety stock”, where DDRP is demand between review periods and DDLT is demand during lead time. Output: A reorder point value stored on each item.
4. Input: Variability in your supplier’s lead time. Action: Calculate safety stock with the lead-time form from an APICS reading, “Safety stock = Z × σ LT × D avg”. An MIT base-stock model lists Z = 1.65 for a 95% service level and Z = 2.33 for 99%. Output: A safety stock value per item, refreshed when lead times change.
5. Input: Quantity on hand and reorder point. Action: Build a filtered table and a scheduled alert listing every item where on-hand stock is at or below its reorder point. Output: A daily reorder list for the buyer.
6. Input: A buyer selects items from the reorder list. Action: A form creates a purchase order with status Draft and lines linked to item IDs. Output: A draft purchase order with a calculated total.
7. Input: The purchase order total and your approval limits. Action: Route by amount. Microsoft documents the same pattern: a Dynamics 365 approval step can run only if the requisition amount is more than USD 10,000, and a Dynamics GP example routes a $2,000 order to one approver and an $8,000 order to two. Output: The order lands in the right approver’s queue, and the creator cannot approve their own order.
8. Input: Goods arrive. Action: The warehouse lead records a receipt against the purchase order. A different role handles supplier payment, following the Dynamics 365 rule of not having the same person acknowledge receipt of goods and process vendor payment. Output: A stock movement row and an updated purchase order status.
9. Input: Every create, edit, approval and receipt. Action: The platform audit log records the user, action and timestamp. NetSuite’s Transaction Audit Trail is the packaged equivalent, showing who made changes and when. Output: A reviewable history for every purchase order.

Build steps 1 to 5 first before adding approvals. A reorder list that the buyer trusts is the foundation the rest of the module depends on.

Costs and timelines: no-code vs custom-coded vs SaaS ERP

Published research gives SaaS ERP licence prices and general ERP project timelines. It does not give ERP-specific build hours for either no-code or custom-coded builds. The table marks those gaps as not stated. Pricing checked November 2026.

For a cost anchor on full ERP projects, Panorama’s 2025 ERP Report puts the median project cost at $450,000. That figure covers ERP implementations generally and does not separate packaged from custom builds.

Budget a no-code build from your own numbers. Start with platform fees for the full user count on the plan that includes audit logs, then add premium connector licences and the hours your process owners spend on design, migration and testing.

Common problems and when to call in developers

Panorama’s 2026 report found that more than a quarter of organizations went over budget and almost a quarter went over schedule. Gartner forecasts that “By 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business case goals.” Each common failure mode has one mitigation from the same research:

• Unexpected technology needs: Among over-budget projects, the most common reason was the unexpected need for additional technology. Mitigation: list every system the module must connect to during Step 1, before choosing a platform.
• Data issues: In 2025, respondents with over-schedule projects most often cited data issues covering integrity, consistency and accuracy. Mitigation: clean and deduplicate before the first trial load.
• Poor adoption: In 2026, respondents with over-schedule projects most often cited organizational issues such as governance, resistance to change and process redesign. Mitigation: role-specific training before go-live, delivered to the pilot group first.
• Integration breaks: Syncs fail silently when a connected tool changes its data. Mitigation: a record-count and field-value check after every sync cycle, as described in Step 4.
• Scope creep: Requests for new modules arrive before the first one is stable. Mitigation: freeze scope until the first module passes one month-end reconciliation.

No-code platforms have documented limits that set the point where developers or a packaged ERP become the better call:

• Transaction volume: Airtable caps API traffic at 5 requests per second per base on all plans. Dataverse defaults to 6,000 requests per user within a five-minute window. Retool-hosted cloud queries time out after 10 seconds by default, with a configurable maximum of 120 seconds.
• Complex accounting rules: Revenue recognition and foreign currency remeasurement need specialist skills. Deloitte’s discussion of newly public companies says post-IPO restatements generally require technical accounting and reporting expertise, with revenue recognition among the five areas. In this guide’s view, keep those accounting rules in a specialist ledger rather than recreating them in a no-code operational app.
• Compliance: PCAOB staff guidance expects controls over user-developed applications, including testing of controls over spreadsheet formulas or logic of queries and scripts. Shell’s governance model, described by Forrester, reserves large, risky apps for IT-led development only.

Thoughtworks puts the boundary plainly: “Low code isn’t a replacement for code.” Bring in developers when the app approaches a documented platform limit, posts entries that auditors will test, or needs logic the visual builder cannot express. Keep the no-code layer for the screens and workflows that sit on top.

Where an AI employee fits in a no-code ERP

Viktor is the AI employee who lives in Slack and Microsoft Teams, connects to 9,800+ tools, and does the work. New teams can also start in the web app at app.viktor.com, and teams that work in Discord can run him in their server. Most of his integrations are one-click OAuth connections, including Airtable, QuickBooks, Xero, Shopify, Google Drive, Jira and GitHub.

Once the ERP app holds clean data, Viktor takes on the reporting and follow-up around it. For the longer definition, see what an AI employee is.

• A team sets up the Monday stock and spend report once in plain English as a scheduled task.
• Each week Viktor pulls on-hand quantities and open purchase orders, writes the summary as an Excel file with formulas or a doc kept current at the same link, and posts it in the thread.
• Event triggers start work when something happens, such as a form submission or a webhook from the ERP app.

Viktor is an AI employee who waits for approval before he changes an account. Viktor’s approval controls mean that money moves, code pushes and customer emails wait for explicit approval.

He posts approval cards in Slack or Microsoft Teams with Approve and Reject, a rejected action never runs, and admins can require approval for any other integration tool. API keys and tokens are added at run time by a gateway, and the AI model never reads them.

For engineering leaders, the boundary with the ERP codebase matters. When the app has custom code in GitHub or Bitbucket, Viktor clones the repository, writes changes on a branch and opens a pull request with context for an engineer to review.

As of October 2026, Viktor holds SOC 2 Type 1, with SOC 2 Type 2 and ISO 27001 in progress, and customer data is never used to train models. Each workspace is isolated from other customers.

Hampton’s published story shows the scale of work involved: in 44 days Viktor connected 24 tools and ran 26 recurring jobs a week, and Hampton avoided $440K in planned hires. That is Hampton’s result, not a forecast for every team. Read Hampton’s story to see how Viktor took on 26 recurring jobs a week in 44 days →

Start with the one report your ops lead rebuilds every week. Hand Viktor your weekly inventory report: start free with up to $100 in credits, no credit card → See how shared workspace credits work on the pricing page.

FAQ

Keep the general ledger in an accounting system the team trusts, and use no-code for operational gaps such as inventory, purchasing and approvals.

Should you build a no-code ERP or buy NetSuite or SAP?

Buy when the system must be your general ledger, handle multi-currency or pass SOX audits. NetSuite charges an annual license fee plus a one-time implementation fee, and SAP Business One pricing is by quote. Build without code when the gap is operational, such as inventory, purchasing or approvals, and your accounting tool stays the book of record.

What is the best no-code platform for an ERP app, and what does it cost?

The best fit depends on your stack. Power Apps suits Microsoft 365 companies at $20 per user per month, paid yearly. Appsmith offers an open-source path with Business at $15 per user per month. Retool provides an inventory template, with Business at $50 per builder per month and $15 per internal user per month, billed annually. Pricing checked November 2026. Choose the plan that includes audit logs and custom roles, since an ERP app needs both.

Which ERP modules should you build first?

Inventory or purchasing comes first. Both modules have clear records, a natural approval step and reports you can reconcile against existing spreadsheets within weeks. Add accounting integration only after the first module passes a month-end check.

Can you connect spreadsheets and existing databases to a no-code ERP?

Yes, Appsmith’s reference lists PostgreSQL, MySQL, SQL Server, Oracle and Snowflake among its databases, and Appsmith, Retool and Budibase support REST API connections. Clean and deduplicate spreadsheet data before import, and check counts and totals afterward.

Is ERP hard to learn?

Yes, at first, because users must learn new screens and new process steps at the same time. Phased rollouts give users more time to learn and adapt, and Prosci ranks training first among value-realization recommendations.

When is no-code not enough for an ERP?

No-code stops being enough when volume hits platform limits, accounting rules need specialist logic, or auditors will test the app’s controls. Airtable’s 5 requests per second per base and Retool’s 120-second maximum query timeout are typical ceilings. At that point, bring in developers for the core logic or move the ledger to a packaged ERP.

Hire your first AI employee with up to $100 in free credits, no credit card →