Build a dashboard on Rails

Scaffold a brand-new Ruby on Rails app whose numbers a team can read at a glance, with Avo 4 (https://avohq.io) as the management UI and its first-class dashboards (https://docs.avohq.io/4.0/dashboards.html) as the centerpiece. Begin with an empty project and build everything.

1. Run rails new with the default stack, then set up sign-in with bin/rails generate authentication (Rails' built-in authentication generator) and run its migration. Add the avo gem to the Gemfile, bundle, run bin/rails generate avo:install, and mount Avo at /avo so it sits behind the session that generator created.
2. A dashboard only means something when real business data sits behind it, so decide what this app actually runs and model it deliberately. Reason out the handful of entities this domain turns on, the states each one moves through over its life (an enum when a record simply changes status, a table of its own when a transition carries its own data), and how they associate. Lay the schema out before you write a single migration. Concepts likely in play here are the customers or accounts you serve, the orders or payments that produce revenue, the signups that arrive over time, and the open work a team tracks, but treat those as things the design has to account for, not a fixed set of tables to copy.
3. Generate an Avo resource for each model with bin/rails generate avo:resource ModelName (https://docs.avohq.io/4.0/resources.html). On every one, set self.title to the attribute a person recognizes, list the columns worth searching in self.search, and add self.includes for the associations the views load so index pages stay fast. Match each field to its column: text and textarea for strings, number and currency for money, select for enums, belongs_to and has_many for the associations you designed.
4. Turn the things this business does to its records (mark an order paid, close a ticket, activate an account) into Avo Actions generated with bin/rails generate avo:action. Because the app is new, put the real behavior in a model method or a small service object and have the action call into it, so the dashboards read the same state these actions write.
5. Add scopes to the resources for the slices a team narrows by, and Avo filters where someone needs to cut a view in the browser. Then build the dashboards this page is about with bin/rails generate avo:dashboard: set grid_cols, add metric cards that each return result from one query over your models (revenue this month, active accounts, open tickets), add chartkick cards for the trends worth watching grouped by week or month, and break a busy board into readable groups with divider label:. Write each metric as a scope on the model so the card and the rest of the app share one definition of the number.
6. Add Pundit and give each person a role, then build a separate dashboard per audience (sales, support, finance) and gate each one with a policy, so a person opens only the board that fits their job and sees no numbers that are not theirs (https://docs.avohq.io/4.0/authorization.html).
7. Fill db/seeds.rb with believable sample data across every model, spread over the past few months and across the lifecycle states, so each metric card and chart renders a real shape instead of a flat line or a zero.
8. Migrate, seed, boot the server, sign in, and open /avo. Open the sales dashboard and confirm a metric card such as revenue this month shows a live figure computed straight from the seeded records, and that a chart card draws its trend across the seeded weeks.