Use cases by function6 use cases
Fixing what you already have: automations, spreadsheets, prototypes and legacy systems
Not every project starts from nothing. Many start with something that half works: seventy Zaps built by three different freelancers, a spreadsheet that runs dispatch, a Lovable prototype that now has paying users, a twenty-year-old Delphi application whose developer has retired, or an AI feature whose bill tripled while usage barely grew.
The complaints are consistent. In freelance marketplaces and automation forums, the most common problems buyers describe after hiring are workflows that report success and silently did nothing, duplicate charges or messages when a run is retried, agents that invent IDs or overwrite fields with blanks, and developers who leave the client without access to their own accounts or any documentation.
The pages here cover finding and fixing silent automation failures, replacing the spreadsheet your operations run on, automating a legacy system that has no API, taking a vibe-coded prototype to production, modernizing legacy code without a big-bang rewrite and an AI cost audit.
Modernization and rescue systems I can build
An AI bill growing faster than your users: a cost audit, model routing and budgets
Traces model spend to each feature and customer, fixes caching, batching and prompt bloat, routes simple calls to small models, and proves quality holds with evals.
OpenAI and Anthropic APIs / Langfuse or Helicone / AI gateway / Data warehouse / Slack
Automating portals and legacy systems that have no API, with a person approving the final click
Keys data into insurer portals and API-less desktop systems with a computer-use model, logs every screen, and waits for a person to approve each submission.
Broker management system / Insurer and carrier portals / A legacy desktop ERP / Computer-use model (Copilot Studio, Claude or OpenAI) / Outlook
Fixing n8n, Zapier and Make automations that report success and did nothing
Audits inherited n8n, Zapier and Make automations, then adds a run ledger, idempotency keys and a daily reconciliation so a green run means the work was done.
n8n / Zapier / Make / Postgres / Slack
Turning a 40-tab dispatch spreadsheet into an internal tool with rules, roles and history
Moves daily planning off a 40-tab spreadsheet into a web tool with validated forms, roles and a full edit history, while people keep Excel for analysis.
Excel and Google Sheets / Postgres / Microsoft 365 single sign-on / The ERP or TMS / Slack
Modernizing a 20-year-old Delphi or VB6 application with AI and tests, one module at a time
Documents what an old application really does, pins that behavior with tests built from real data, then replaces it module by module while it keeps running.
The legacy application (Delphi, VB6, Access, old PHP or .NET Framework) / SQL Server or Access database / Claude Code / The target stack / CI pipeline
Taking a vibe-coded app to production: secure data, reliable billing, maintainable code
Audits a Lovable, Bolt or v0 app's Supabase policies, secrets and Stripe billing, fixes what exposes data or money first, then adds tests and a deploy pipeline.
Lovable, Bolt or v0 / Supabase / Stripe / Vercel / GitHub
How I approach something that already exists
Measure before changing anything
Logs, run history, error rates and costs come first. It is common to find that the problem people complain about is not the one actually costing money.
Make failures loud
A system that fails silently is worse than one that stops. Every run records what it did, and anything unexpected, including an empty result, raises an alert.
Tests pin behavior before refactoring
Characterization tests capture what the old system does today, including its quirks, so changes can be checked against reality rather than memory.
Replace in slices
Big-bang rewrites fail more often than they succeed. New pieces are built around the old system and take over one module at a time, with a way back at each step.
Hand back the keys
Credentials in your name, the code in your repository, runbooks written down. You should never again be locked out of your own automation.
Frequently asked questions
Can you fix our existing n8n or Zapier automations?
Usually, yes. The first step is an audit of what runs, what fails and what fails silently. Many problems are fixed in place with better error handling, idempotency and alerts. Workflows that move money or change records of truth are often better moved to a small owned integration layer where every run can be inspected.
Should we rewrite our legacy application or modernize it gradually?
Gradually, in almost every case. A full rewrite has to rediscover every undocumented business rule at once. Documenting the old system, pinning its behavior with tests and replacing it module by module keeps the business running throughout. The exception is when a standard SaaS product now does what the old system did.
Is our Lovable or Bolt app ready for production?
Possibly not, and it is worth checking before you have more users. The common gaps are database access rules left open, secret keys in the browser, no tests on the paths that take money, and payment webhooks that process twice. A focused audit finds these quickly and tells you what to fix versus rebuild.
How do I reduce our OpenAI or Anthropic API costs?
Attribute cost to features first, then apply the usual levers: prompt caching, smaller models for simple steps, batch processing for anything not urgent, tighter retrieval and output limits. An evaluation set protects quality while you cut, so savings do not quietly come out of accuracy.
Also browse: n8n · Excel and Google Sheets · SaaS · Operations and logistics · all use cases