Build an ATS on Rails

Scaffold a brand-new applicant tracking system as a fresh Ruby on Rails app with Avo 4 as the management UI (https://avohq.io, docs at https://docs.avohq.io/4.0/). Nothing exists yet: no repo, no database, no models, so build it from zero.

1. Run rails new to generate the application with sensible defaults, then set up sign-in with Rails' built-in authentication generator (bin/rails generate authentication). Add the avo gem to the Gemfile, 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 first principles before you write a single migration. Reason about what recruiting genuinely requires: the people applying, the openings they apply to, where each person sits in a hiring pipeline, and the feedback that accumulates as they move through it. Decide which of those are their own tables and which are attributes, whether a pipeline stage is best expressed as an enum on a record or as its own table with a history of moves, and how everything associates. Sketch the full schema, then generate the migrations and models to match. Treat resumes and cover letters as Active Storage attachments and outreach touchpoints as records you can list per candidate. Nothing here is a fixed list to copy; it is the ground your design has to cover.
3. Generate an Avo resource per model with bin/rails generate avo:resource. On the record recruiters open most, set self.title to its most recognizable attribute, give self.search a ransack query across the fields people are looked up by such as name and email, and set self.includes to preload the associations the Index and Show views render. Match field types to the columns you chose: a badge for the pipeline stage on Index and Show with a select for editing it on the form, a file field for the resume attachment, belongs_to for the opening, and has_many for the feedback timeline.
4. Express the pipeline's verbs as Avo Actions. Because the app is new, put the real work in model methods or small service objects and have each action call them: an advance-stage action moves the record forward and stamps who did it and when, a reject action records the reason. Add filters and scopes over the stages and associations you modeled so a recruiter can narrow the list to one opening, one stage, or one owner and see who is stuck where.
5. Build a dashboard that surfaces what a hiring team watches: counts per stage, open roles, and recent activity (https://docs.avohq.io/4.0/dashboards.html). Add filters and scopes to the resources to back it.
6. Authorize with Pundit policies covering real hiring roles so a recruiter sees the whole pipeline, a hiring manager sees only the openings they own, a coordinator can schedule without rejecting, and sensitive fields like compensation render only for the roles cleared to read them (https://docs.avohq.io/4.0/authorization.html). Add a policy-guarded destroy action on the candidate that cascades to its attachments and feedback, so a GDPR deletion request is one provable step.
7. Seed the database with realistic sample data: several openings, candidates spread across every pipeline stage, resumes attached, and a few rounds of interview feedback, so every screen and dashboard has something real to show.
8. Boot the app, open /avo, and move a seeded candidate forward a stage. Confirm the move is stamped, the dashboard counts shift, and a lower-privileged role is blocked from the fields and actions its policy denies.