Build an ERP on Rails

Stand up a fresh Ruby on Rails application that runs the useful fifth of an ERP, with Avo 4 as the operations UI (https://avohq.io, docs at https://docs.avohq.io/4.0/). There is no existing app or schema yet, so scaffold the whole thing, and resist the urge to rebuild a full suite: build only the screens the business actually runs on.

1. Run rails new for a new app with Postgres as the database and the usual defaults. Set up sign-in with the built-in Rails authentication generator (bin/rails generate authentication). Add the avo gem, bundle, run bin/rails generate avo:install, and mount Avo at /avo so it sits behind the authentication you just generated.
2. Work out the data model from the ground up before touching a migration. Reason about what this operation genuinely needs: the core entities, the lifecycle each one moves through (a status enum where a column is enough, its own table where a state carries data of its own), and how they relate to each other. Products, orders and their line items, purchasing, stock, invoices, and the customers behind them are the kind of concepts an ERP has to cover, so use them to pressure-test your design rather than as a fixed list to transcribe. Sketch the entities and associations, then write the migrations and models.
3. Generate an Avo resource for each model with bin/rails generate avo:resource, and wire them together with belongs_to and has_many fields so a person clicks from an order to its customer and line items instead of joining tables in their head. Give each resource a readable self.title, self.search over the columns people look things up by, self.includes for the associations you render, and field types matched to the columns you created: a badge over a status column with sensible option colors, number and money fields for amounts, dates for anything scheduled.
4. Turn the operations into Avo Actions behind confirmations, the verbs the business runs on, such as receiving stock, approving a purchase order, or marking an invoice paid. Since the app is new, put the real logic in model methods or small service objects and have each action call into those rather than mutating rows inline.
5. Add the morning-check lists as scopes and filters driven by your own columns, such as stock below its reorder point, invoices past due, and purchase orders awaiting approval, then build a dashboard over the same Postgres the app writes to for the numbers the team watches: stock levels, receivables, order volume (https://docs.avohq.io/4.0/dashboards.html).
6. Gate everything with Pundit authorization so each role sees only what it should, warehouse staff on stock and receiving, finance on invoices and receivables, and so on (https://docs.avohq.io/4.0/authorization.html).
7. Seed realistic sample data across every model, products in stock and low, orders in various states, purchase orders awaiting approval, and invoices spanning draft, sent, paid, and overdue, so every list, scope, and dashboard has something to show.
8. Boot the app, open /avo, click from an order through to its customer and their invoices, and run one operation end to end by marking a seeded overdue invoice paid.