Services
Grails upgrades first.
Full-stack SaaS when you need it.
You work with me directly, from the first call to the last deploy. For Grails work, the best place to start is an assessment, so you know the whole path before you commit to it.
Start here · Fixed price
Grails upgrade assessment
Before you commit to an upgrade, find out exactly what it involves. I go through your app and hand you a plan you can act on, with me or without me.
What you get
- An inventory of your plugins and dependencies, and what happens to each one
- The breaking changes at each major version on your upgrade path
- A stepwise upgrade plan, including the route to Grails 7
- A risk and effort estimate
- A written report, plus a walkthrough call
Grails upgrades & legacy rescue
I get legacy Grails apps onto a supported stack without a rewrite. I plan the upgrade path, replace dead plugins, move Java 8 to 17, fix what breaks in GORM and Spring Security, and rehearse the cutover before it happens. I keep shipping features along the way.
Proof
- Upgraded two large Grails 2.5.6 applications to 6.2.3, one through every major version (3 → 4 → 5 → 6) in about six months. Both are now in final pre-launch testing. Case study
- Rehearsed a production cutover on a restored copy of the production database: one clean pass in about 17 minutes, with zero schema failures. Case study
- Technical lead on a live production Grails platform for a client I've worked with since 2012. Case study
SaaS from zero
I build SaaS end to end, from the domain model through auth and multi-tenancy, Stripe billing, AWS infrastructure and AI features to CI/CD. I can do it as a senior IC, a technical lead, or a fractional CTO directing other developers.
Proof
- Solo-built a multi-tenant inspection and work-order SaaS on Grails 6.2.3 for a property-inspection firm: 55 domain classes, 114 controllers and 327 test files in about 13 months. Case study
- Have run my own SaaS since 2016. Its Grails 6 rebuild has 14 dedicated Stripe services. Case study
- Fractional CTO for a serial founder across about eight ventures. Case study
JVM data & performance
Large-dataset sync, multi-datasource GORM and throughput tuning for JVM apps that have outgrown their original design.
Proof
- A clinical-trials platform over 500K+ studies with multi-datasource GORM. I re-engineered its data-sync pipeline and benchmarked it at up to 83× the original throughput. Case study
- Earlier: near-real-time vehicle tracking at Spireon.
AI integration & AI-accelerated delivery
AI features built to run at scale, and AI coding agents directed with tests and independent verification. Many people use AI; the point is building it to run reliably and checking its work.
Proof
- An OpenAI content pipeline behind a ~2M-page site built from 500K+ clinical trials (3,500 RPM / 200K TPM rate limiting, Batch API). Case study
- A coverage-gated AI test loop I built with Claude Code added ~3,650 tests in 8 days and surfaced 19 real bugs, all fixed. Case study
- Claude Code directed under a plan → audit → run → audit workflow, with enforced project rules and a second, independent verifier.
How I use AI
AI-assisted, human-reviewed
Claude Code has been my standard development workflow on every active project since September 2025: about 2,950 commits across 13 repositories. It's disciplined, not a shortcut.
The session that writes code never approves it
A separate session re-runs the tests, reads the diff and checks the page. Then I approve every commit myself.
Tests have to earn their place
A coverage-gated AI test loop I built keeps only passing tests that raise coverage. On one app it added ~3,650 tests in 8 days and surfaced 19 real bugs, all fixed.
Context engineering
I cut per-session AI context by 75–82% by restructuring project instructions into lean core rules, path-scoped rules and on-demand docs.
Parallel agents, isolated
Independent tasks run as parallel agents in separate git worktrees, with the effort matched to the risk of the change.
Guardrails in CI and in writing
A CI gate that blocks spec/code drift, commit linting and a coverage floor, plus written "never" rules: no blind edits, credentials entered only by the owner, and approval to commit is not approval to push.
Written down
I wrote a 587-line Claude Code best-practices guide and reusable orchestration playbooks that I work from.
Experience
Where Grails upgrades break
These are the problems I've hit and fixed in real upgrades. An assessment looks for each of them in your app.
- Grails 2 → 3 is the hardest step: Gradle, Spring Boot, YAML config and a new plugin system arrive at once. Going one major version at a time keeps every step testable.
- Every Grails 2 plugin has to be upgraded, replaced or dropped.
- Legacy password hashes stop working when the Spring Security encoder changes, unless you plan for it.
- Turning on CSRF protection breaks AJAX calls.
- Moving from
dbCreate: updatetovalidateexposes column types that need fixing. - Multi-datasource GORM hides lazy-loading traps.
- Quartz jobs can silently never register.
- One dependency pin can make every request run twice.
- Date handling moves to
groovy-dateutilandjava.time, and timezone bugs surface. - The cutover itself: rehearse it on a production snapshot before you do it for real.
Engagement terms
How I work
- ContractHourly or fixed-scope
- RemoteUS Pacific time, from Yorba Linda, CA
- Availability40+ hours a week
- Directly with meOne senior engineer, not an agency
Tell me what version you're on and what's breaking.
I'll tell you what the path looks like.