A written audit of your Rails application. Five business days. $2,500, fixed.
You get a report that says where the application stands, what needs fixing, how many developer-days each piece of work takes, and what to do first. It is written so the person who approves the budget can read it without a developer in the room.
The button opens an email to me. We pick a time and talk through your application before you commit to anything.
The engagement
- Price
- $2,500, fixed
- Time
- Five business days
- Scope
- One Rails application
- You provide
- Access to one repository, which is only ever read, and about 60 minutes of an engineer's time
- You receive
- A PDF report: five pages for the budget holder, then the full technical register
- Included
- A 30-minute kickoff call and a 60-minute walkthrough of the findings
- Guarantee
- If the report tells you nothing you didn't already know, you don't pay the second half
What you get
One PDF in two layers, because two different people need to read it.
The first five pages
For whoever approves the budget
- Where the application stands, in plain language.
- What was examined, so you know what the conclusions rest on.
- The work, broken into three to five named packages, each with a cost in developer-days.
- The order to do them in, and why.
The rest
For the engineers who do the work
- The full technical register: every finding, with its severity.
- File-level evidence for each one, so nobody has to take it on trust.
- An estimate per finding, which is where the package totals come from.
- The package each finding belongs to, so the two layers line up.
What it costs and how long it takes
$2,500
Fixed price, one application
Not an estimate and not a day rate. Half on signature, half on delivery. The price is on this page so you can approve it without a procurement process.
5 days
Business days, from access to report
The clock starts when I can read the repository. It includes a 30-minute kickoff and ends with a 60-minute walkthrough of the findings.
What is not in scope
This is an audit of one application's code and configuration. These are different jobs, and it is better you hear that now than on day five.
No penetration testing
Nobody attacks your running application. The audit reads code and configuration.
No load testing
It can point at a missing index. It does not measure how the application behaves under traffic.
No infrastructure or cloud review
Your AWS account, network and servers are outside the repository, and outside the audit.
No compliance attestation
The report is not a SOC 2, HIPAA or PCI document and can't be used as one.
No code changes
Nothing is fixed, committed or opened as a pull request. You get the plan, not the patches.
The guarantee
If the report contains nothing you didn't already know, don't pay the second half.
You are the judge of that. An audit that only confirms what your team already had on a list has not earned its full price.
Who it is for
Three situations where an independent read of the codebase pays for itself.
You just inherited it
A Rails codebase is now yours, and you didn't write it.
The people who built it have moved on, or you have just taken over the team. Before you commit to a roadmap, you need a read of the application from someone with no stake in how it got this way.
You are hiring
You are about to bring in senior Rails developers.
Good candidates ask what state the application is in. The audit gives you an honest answer, and gives the people you hire a prioritized list of work for their first months instead of a period of discovery.
You are upgrading
You are about to commit to a major version upgrade.
A Rails upgrade is quoted on guesses until someone has looked at what is in the way: unsupported versions, gems that block the path, tests too thin to catch regressions. The audit finds those before the budget is set.
What you need to provide
Access to one repository
I only ever read it. No commits, no issues, no pull requests. Access is removed when the report is delivered.
About 60 minutes of engineering time
One conversation with someone who knows the application, so the report reflects how it is actually used.
That's all
No staging environment, no production credentials, no database dump, no customer data.
How it fits in five days
The tooling does the collecting. I do the judging.
RailsHealth is software I built after years of doing this audit by hand. Eleven automated checks cover gem and package advisories, version support, production security configuration, tests, CI, deployment, monitoring, dependencies and the database schema. They run in minutes and produce the same evidence every time, which leaves the five days for reading the code and deciding what the findings mean for you.
What the checks keep finding in real Rails apps
- Median gem CVEs per repo1 (worst: 29)
- Apps on EOL Rails2 of 6
From scans of public OSS Rails apps (Discourse, Mastodon, Forem, OpenProject, Errbit, Diaspora).
Questions people ask before they book
Do you store or modify my code?
▼
No. Access is to one repository, and I only ever read it. Nothing is ever written to it: no commits, no issues, no pull requests. I keep the analysis results that go into your report, not your source files. When the audit is delivered, the access is removed.
Is this the same kind of audit FastRuby.io or OmbuLabs would do?
▼
It is the same kind of work: a person reads your application and writes down what they found and what to do about it. The difference is how the time is spent. RailsHealth's tooling runs the mechanical checks in minutes: gem and package advisories, version support dates, configuration hardening, schema and index review, CI and deployment setup. That leaves the five days for the part that needs judgement, which is deciding what matters, how much work it is, and what order to do it in. The tooling is how the audit gets done thoroughly in five days rather than three weeks. It is not a substitute for a person reading the code.
How is this different from running bundler-audit and Brakeman myself?
▼
Those tools give you lists. The audit starts where the lists stop: which findings matter for this application, which ones are noise, how the real ones group into pieces of work a team can schedule, how many developer-days each piece is, and which to do first. The report is written so the person approving the budget can read the first five pages without a developer in the room.
Will this work on a Rails 4.2 / 5.x / pre-Hotwire app?
▼
Yes. The automated checks read your Gemfile.lock, schema.rb and config files, so they work on any Rails version. Older applications usually have more findings, which is the reason to audit them, and the report says which upgrade path to plan for.
Do you need a running environment, production access, or our data?
▼
No. The audit works from the repository. I don't need a staging server, production credentials, a database dump or customer data, and the automated checks never execute your code, install your gems or run your tests.
What is examined?
▼
Four areas. Security: known vulnerabilities in gems and JavaScript packages, and production security configuration. Application quality: Rails and Ruby version support, and the state of the test suite. Infrastructure: CI, deployment setup and monitoring. Code health: dependency freshness, database schema and indexes, and code quality tooling. Security carries the most weight because that is where not knowing costs the most.
Is there a score?
▼
Not in the report. A single number averages away what you need to know: an application with four critical vulnerabilities and a good test suite can still land near 75 out of 100, and 75 sounds fine. The report leads with how many findings there are at each severity and how many developer-days they add up to, because those are the numbers you can make a decision with. If you audit again later, it shows what was resolved, what is new and how the days moved.
What happens after the report is delivered?
▼
Whatever you decide. The work packages are written so your own team or any competent contractor can pick them up without me. If you want to talk through the remediation, that is a separate conversation and there is no obligation to have it.
We have more than one Rails application. Can you audit all of them?
▼
Each audit covers one application, so the price and the five days stay fixed. A second application is a second audit.
Who does the work?
▼
One person: Rob Bazinet, a Rails developer since 2007. There is no team behind the name and nothing is subcontracted. The about page says more.
Find out where your Rails application stands.
$2,500, fixed. Five business days. One application.