How I Build Software With AI, and What ERP Really Means for a Small Business

The short answer: An ERP (enterprise resource planning) system is the single shared record that ties a company's sales, production, inventory, purchasing, and accounting together, so the shop floor and the P&L read from the same numbers. DhyanaTech is a Knoxville software company that builds ERP for fabrication shops. We also help small businesses set up the databases, software, and AI workflows that connect their daily operations to the decisions made at the top. This post lays out exactly how I do that: the models, the tools, the stack, the security, and the math on whether it pays.

A conversation that stuck

A few weeks ago I sat down with a shop owner running an ERP built on Microsoft Access. Every time they asked their developer for something custom, a new report or a new screen, the answer was some version of "not without risk." The developer told them that because they were still on the old database, every change to the front end compounded problems in the back end. The only real fix, he said, was reconstructing the back end, and he'd have to do it without disrupting the people using it every day.

Was he stonewalling? I don't think so. He was telling the truth about the house he's standing in. But the explanation deserves a name, and the owner deserves to know it's not the only way to build.

What does ERP really mean?

Most people hear "ERP" and picture production scheduling software. That's a piece of it. The bigger idea is that a business should record a fact once and let every department use it. The quote becomes the order. The order becomes the work ticket. The work ticket becomes the inventory draw, the labor cost, the invoice, and a line on the P&L. Nobody retypes it.

When that chain holds, the owner can answer the questions that matter. What's my real margin by job? Which customers are profitable once you count the rework? How much cash is tied up in finished goods sitting in the field? Those are KPIs, and a KPI is only as honest as the data underneath it. When data gets manually entered several times across spreadsheets and disconnected programs, every report downstream inherits every mistake upstream.

That's why I call ERP a planning tool as much as a production tool. It's how you see the whole board.

Why does the old developer keep saying no?

The phenomenon that shop owner ran into has a few technical names, and they stack on top of each other.

Tight coupling. In a classic Access application, forms, reports, queries, macros, and VBA code are often bound directly to the tables. There's no contract layer between the screen and the data. Rename a field or split a table, and every form, query, and script that touched it can break. The front end and back end aren't two layers. They're one piece of welded steel.

Technical debt. Ward Cunningham coined the term in 1992. Every shortcut taken to ship faster is a loan, and the interest is the extra effort every future change costs. After fifteen or twenty years of patches, the interest payments eat the budget. Stripe's Developer Coefficient survey found the typical developer spends about 13.5 hours a week on technical debt and another 3.8 hours on bad code, which works out to roughly 42% of a 41-hour week. That survey was published in 2018 and drew on more than 1,000 developers and more than 1,000 executives across five countries.

Increasing complexity. Software researcher Manny Lehman observed decades ago that a system in use keeps getting more complex unless someone does deliberate work to simplify it. Legacy systems rarely get that work, because the budget is spent keeping them alive.

No safe place to practice. Many older setups have no version control, no migration history, and no staging copy of the database. Every change is surgery on the live patient.

Platform ceilings. Microsoft's own specifications cap a single Access database file at 2 GB, and list a maximum of 255 concurrent users. In practice the ceiling comes sooner. One longtime Access trainer notes that real-world databases start to get wobbly around 20 to 30 active users hitting the same back end.

Put those together and you get exactly what that developer described. The front end can't change without the back end changing, the back end can't change without risking everyone's day, and every workaround adds more debt. It's a real problem, not an excuse.

Why can DhyanaTech customize so easily?

Because the building is framed differently. Here's what's different under the hood.

The database is PostgreSQL, the most widely used and trusted open-source relational database around. Every change to the database's structure is written as a migration file, a small, dated script checked into GitHub right next to the application code. We can see every change ever made, when it was made, and why. We can replay the whole history onto a fresh copy and test against it before anything touches production.

The front end talks to the database through an API layer, not directly to the tables. The screen asks for data, the API hands it over, and the rules about who may see what live inside the database itself. Change a screen and the database doesn't care. Change the database and TypeScript types generated from the schema immediately flag any screen that needs updating, before a customer ever sees it.

Every branch of code gets its own preview deployment on Vercel. I can build a new feature, click through it on a real URL, and show it to a customer before it goes live. If something's wrong, production never knew about it.

And there's the part that isn't technical at all. There's no handoff chain here. The person who writes the code is the same person who stood in the shop, ran production, and estimated the jobs. Nothing gets lost translating a requirement through three companies and two time zones. When a customer tells me the QC checklist needs one more field, I know why they need it before they finish the sentence.

This summer we shipped roughly 37 releases in six weeks. That pace isn't recklessness. It's what happens when changes are small, tracked, and tested, and when the builder knows the work.

I learned to build walls before I learned to build software, and the rules carried over. Every course has to be laid straight, plumb, and level all the way up, or the wall fails no matter how good the top looks. And the strength of a masonry wall isn't only in what you see. It's the rebar in the grouted cores, the joint reinforcement in the bed joints, and the brick ties anchoring the veneer to the backup wall. Nobody admires that steel once the wall is finished, but it's why the wall is still standing fifty years later. That's how I approach a codebase. The architecture, the documentation, the migrations, and the security policies are the steel inside the wall. I don't accept technical debt as the cost of doing business. I'd rather lay it right the first time than spend the next ten years paying interest on a crooked course.

What's in the stack?

• Supabase for the database, authentication, file storage, and serverless Edge Functions, all built on PostgreSQL
• Vercel for hosting the web application, built with Next.js
• GitHub for version control, holding every line of code and every database migration
• VS Code as the workbench
• Claude Code running inside VS Code as my development partner, connected to Supabase and GitHub through MCP servers and the command line

Who else runs on these tools?

You're in good company on this stack. A few examples:

PostgreSQL: OpenAI has described running ChatGPT's core data for roughly 800 million users on a single primary PostgreSQL instance handling writes, with nearly 50 read replicas spread across regions. Instagram keeps user data, relationships, and media records in PostgreSQL; Reddit, Spotify, and Twitch also run it in production, and NASA uses it on the International Space Station. In the 2025 Stack Overflow Developer Survey, 55.6% of developers reported using PostgreSQL, up from 48.7% the year before, opening a 15-point lead over second-place MySQL.

Supabase: Mozilla uses Supabase to store embeddings for AI search across its MDN documentation, Epsilon3 builds mission software for NASA on it, and Pebblely scaled to millions of users on it. Published Supabase customer stories also include Lovable, Chatbase, Brevo, eXp Realty, Phoenix Energy, and Udio.

Vercel: Vercel lists Under Armour, Nintendo, The Washington Post, Porsche, and Zapier among its customers.

Is this stack safe? Is it secure?

Short answer: the platforms are audited to enterprise standards, and the security of the application is shared between the platform and the builder. Anybody who tells you it's all automatic is selling something.

On the platform side, Supabase is SOC 2 Type 2 compliant, ISO 27001 certified, and HIPAA compliant for customers who sign a Business Associate Agreement. Vercel holds a SOC 2 Type 2 attestation covering security, confidentiality, and availability, and is certified to ISO 27001:2022. Every Vercel deployment is served over HTTPS with SSL certificates generated automatically at no charge. Its firewall protection and DDoS mitigation apply on every plan.

On the builder side, the big one is Row Level Security. Supabase makes it safe to access data straight from the browser only when RLS is turned on, and once it is, the public key can reach nothing until policies explicitly allow it. The public key is safe to expose with RLS enabled because every row request is checked against your policies and the signed-in user's token, but secret and service-role keys bypass RLS and must never touch the front end. Every table in DhyanaERP has RLS enabled and policies written for it. That's not optional in my shop.

Now the honest part. No platform is bulletproof. In April 2026, Vercel disclosed that an attacker compromised Context.ai, a third-party AI tool one Vercel employee used, took over that employee's Google Workspace account, and worked into Vercel systems to decrypt non-sensitive environment variables. Vercel reached out to a limited subset of affected customers and advised everyone to review their environment variables and use its sensitive environment variable feature.

There are two lessons in that for any small business. First, mark every secret as sensitive and turn on multi-factor authentication everywhere. Second, and this is the one people miss, be careful which AI tools you grant access to your accounts. An AI assistant with an OAuth token is a door. Know what's behind it.

How I use AI to build software

Which model should you use?

Anthropic's current lineup runs from fast and cheap to slow and brilliant. Anthropic recommends starting with Claude Opus 5 for most workloads, and reaching for Claude Fable 5.1 for demanding reasoning and long-horizon agentic work. Sonnet 5 and Haiku 4.5 sit below those for speed-sensitive jobs. The price gap matters: Fable 5.1 lists at $10 per million input tokens and $50 per million output tokens, while Opus 5 lists at $5 and $25.

So I split the work the way a contractor splits design from construction. Fable writes the plan. Opus builds it.

I start a session on Fable and have it study the codebase and write a development plan as a markdown file (PLAN.md). The plan covers phases, files to touch, migrations to write, acceptance criteria, and a rollback path. Then I switch models and have Opus read that file and execute it one phase at a time, checking boxes as it goes.

Here's why the split matters in dollars, at API list prices, for an example feature (token counts are illustrative):

• Planning on Fable: 200,000 input tokens × $10/M = $2.00, plus 30,000 output × $50/M = $1.50, for $3.50
• Building on Fable: 3,000,000 input × $10/M = $30.00, plus 400,000 output × $50/M = $20.00, for $50.00
• Building on Opus instead: 3,000,000 × $5/M = $15.00, plus 400,000 × $25/M = $10.00, for $25.00

The all-Fable total is $53.50. The split total is $3.50 + $25.00 = $28.50. That's ($53.50 − $28.50) ÷ $53.50 = 46.7% less, with the best thinking spent where thinking matters most. On a subscription plan the same logic applies to your usage limits instead of your invoice.

Claude chat or Claude Code?

I use chat for thinking: research, writing, strategy, sorting out a problem before I touch code. Claude Code is for doing. It works inside the actual project folder, reads the files, runs commands, edits code, and tests it. I run it inside VS Code so I can watch every change it makes in the same window where I'd make it myself.

LLMs or AI APIs?

A chat subscription is a tool you use. An API is a tool you build into your software. When a DhyanaERP user asks our built-in assistant a question, that's an API call running inside our app, with our rules and our data boundaries around it. Some businesses only need the first kind. Some need both. Part of what I do is help sort out which.

Skills, memory, and global versus project settings

Claude Code reads standing instructions from files called CLAUDE.md, and they come in layers. Personal instructions that follow you everywhere live in ~/.claude/CLAUDE.md, project instructions shared with the team live in CLAUDE.md in the repository, and CLAUDE.local.md holds personal notes for one project. Settings work the same way. When a setting appears in more than one place, local overrides project, project overrides user, and organization-managed settings override everything.

My rule of thumb: habits go global, facts about a codebase go in the project. "No em dashes in anything I publish" is global. "This project uses Supabase and every table needs RLS" is project.

Skills are folders of instructions Claude loads when a task calls for them. I've built a set of them for my own work, from writing in my voice to legal and marketing questions, organized like a router that sends each job to the right specialist.

My "learn from mistakes" trick

Every AI coding session costs tokens, and the most expensive tokens are the ones spent making the same mistake twice. So my project CLAUDE.md carries a standing rule along these lines:

## Lessons Learned

Before starting any task, read this section.

When a fix fails, a test breaks, or I correct you, add a one-line
rule here describing the mistake and the right approach before moving on.

Over time that section becomes a field manual written by the job itself. Claude stops repeating mistakes it has already paid for once.

MCP: the real game-changer

In November 2024, Anthropic introduced the Model Context Protocol as an open standard for how AI systems connect to outside tools and data, and OpenAI and Google DeepMind later adopted it. In plain terms, MCP is a universal plug between an AI and the systems your business runs on.

Before MCP, my workflow was copy and paste. I'd write an Edge Function, copy it into the Supabase dashboard, deploy it, test it by hand, copy the error back into chat, and go around again. Now Claude Code talks to Supabase directly. It can read the real schema, write a migration against the tables that actually exist, check the logs when something fails, and generate fresh types. That one change collapsed hours of round trips into minutes, and it's a big part of why development speed changed so much over the last year.

It deserves guardrails. Supabase recommends scoping its MCP server to one specific project, and running it read-only by default so SQL executes as a read-only database user and tools like deploying functions or applying migrations are disabled. I turn write access on deliberately, for development work, never by accident.

How to wire it all together

1. Create a GitHub repository for the project.
2. Connect the repository to Vercel so every push deploys, and every branch gets its own preview URL.
3. Create a Supabase project, install the Supabase CLI, and keep all migrations in the repository.
4. Store keys in Vercel environment variables, marked sensitive. Only the public key ever reaches the browser.
5. Install Claude Code in VS Code and write your global and project CLAUDE.md files.
6. Add the Supabase MCP server, scoped to one project, read-only until you choose otherwise.
7. Turn on RLS for every table, write the policies, and test them before launch.

Does it pay? An ROI study with the math shown

Here's a worked example for a 25-person fabrication shop with four office people who spend part of every week re-entering or reconciling data that already exists somewhere else. Plug in your own numbers; the method matters more than my inputs.

Labor cost. The Bureau of Labor Statistics puts the median wage for production, planning, and expediting clerks at $25.91 an hour. Wages aren't the whole cost of an employee, though. For private industry, wages and salaries make up 70.0% of employer compensation costs, with benefits covering the other 30.0%. So the loaded hourly cost is $25.91 ÷ 0.70 = $37.01.

Re-keying time (assumption). Four people × 5 hours a week × 50 weeks = 1,000 hours a year. At $37.01, that's $37,014 a year spent typing things twice.

Errors. Research on manual data entry puts error rates at roughly 1% per entry. If a job's key fields get entered in four different places, the chance a given field picks up at least one error is 1 − 0.99⁴ = 3.94%. Enter it once, and it's 1%. That's a 75% cut in the error rate. Say the shop runs 400 jobs a year with 10 key fields each, or 4,000 fields:

• Entered four times: 4,000 × 3.94% = 157.6 expected field errors
• Entered once: 4,000 × 1% = 40 expected field errors
• Errors avoided: 117.6

Why does catching errors early matter so much? Labovitz and Chang's 1-10-100 rule holds that preventing an error costs about $1, correcting it inside your system about $10, and letting it reach real operations about $100. Assume 10% of the avoided errors would have escaped to production, and each escape costs $1,000 in rework (assumption). That's 11.76 × $1,000 = $11,760 a year.

Total annual benefit: $37,014 + $11,760 = $48,774

Now, what does it cost to capture that? There are two honest paths, and this essay is about both.

Path one, buy DhyanaERP. It's $18,000 a year per shop, with unlimited users and self-serve setup included at no charge. It's a flat annual subscription, so the math looks the same every year:

Path two, hire DhyanaTech to set you up. This is a consulting engagement, not a product subscription. I map your workflow, stand up the stack, connect your data, and define the KPIs that roll up into your P&L, for a one-time flat fee of $15,000, with no ongoing fees from me. After that, the software is yours to run:

Now the conservative case, for either path. Cut the time savings in half to 2.5 hours per person, and count zero benefit from errors. That's 500 hours × $37.01 = $18,507 a year. Even then, DhyanaERP nets $507 in year one and pays for itself in 11.7 months, and the one-time setup engagement nets $3,507 in year one, pays back in 9.7 months, and is pure return after that. Either way, it pays for itself inside a year, and every year after that it's nearly all return.

The legacy-maintenance angle. If a shop pays an outside developer $40,000 a year (assumption) and the Stripe 42% figure holds, about $40,000 × 0.42 = $16,800 of that goes to fighting old code instead of building anything new.

These are illustrations, not promises. Your numbers will differ. What won't differ is the shape of the math: data typed once costs less and breaks less than data typed four times.

How I can help your business

I can help you choose the right AI models for the work, sort out when you need a chat subscription versus an API, and set up skills, memory files, and project settings so the tools learn your business. I can stand up Supabase, Vercel, GitHub, and VS Code with Claude Code, connected through MCP with the guardrails on. I can map your workflow from quote to cash, build the database that ties it together, and define the KPIs that roll up into your P&L. That covers the revenue operations side (the path from lead to invoice) and the development operations side (how software gets built, tested, and shipped). And if you want to write your own code, I'll teach you to do it safely. Whichever way you go, we'll make it easy.

I'm a third-generation mason. I studied computer science at Ozarks Technical Community College, and later earned an AAS in Civil Engineering Technology, summa cum laude, from Pellissippi State. I've run production, estimated jobs, and managed a shop floor. I treat LLMs and APIs the way I treat a trowel or a multimeter: tools in the box, picked for the job.

Sources

1. Supabase, Security at Supabase: supabase.com/security
2. Supabase Docs, Row Level Security: supabase.com/docs/guides/auth/row-level-security
3. Supabase Docs, Securing your data: supabase.com/docs/guides/database/secure-data
4. Supabase MCP server (GitHub): github.com/supabase-community/mcp-server-supabase
5. Supabase, Enterprise and customer stories: supabase.com/enterprise and supabase.com/customers
6. Vercel Docs, Security and Compliance Measures: vercel.com/docs/security/compliance
7. Vercel Docs, Security overview: vercel.com/docs/security
8. Vercel Knowledge Base, SOC 2 attestation: vercel.com/kb/guide/is-vercel-soc-2-compliant
9. Vercel Knowledge Base, April 2026 security incident bulletin: vercel.com/kb/bulletin/vercel-april-2026-security-incident
10. G2, Vercel product profile: g2.com/products/Vercel/reviews
11. Anthropic, Models overview: platform.claude.com/docs/en/models/overview
12. Claude Code Docs, Settings: code.claude.com/docs/en/settings
13. Wikipedia, Model Context Protocol: en.wikipedia.org/wiki/Model_Context_Protocol
14. Microsoft Support, Access specifications: support.microsoft.com/en-US/Access/access-specifications
15. Richard Rost, Understanding Microsoft Access real-world limits: richardrost.substack.com
16. Stripe, The Developer Coefficient (2018), via Lightspeed Venture Partners: lsvp.com
17. I Programmer, Old and Bad Code Waste Billions (2018): i-programmer.info
18. U.S. Bureau of Labor Statistics, OEWS May 2023, Production, Planning, and Expediting Clerks: bls.gov/oes/current/oes435061.htm
19. U.S. Bureau of Labor Statistics, Employer Costs for Employee Compensation, June 2026: bls.gov/news.release/archives/ecec_09092026.htm
20. Barchard and Pace (2011), UNLV data entry research: img.faculty.unlv.edu/lab/newsletter/issue3/data-checking
21. FSI, The 1-10-100 Rule (Labovitz and Chang): fsiedi.com/1-10-100-rule
22. Vonng, PostgreSQL in the 2025 Stack Overflow Survey: blog.vonng.com/en/pg/so2025-pg
23. Gend, summary of OpenAI's Scaling PostgreSQL for ChatGPT (January 2026): gend.co/blog/scaling-postgresql-800-million-chatgpt-users
24. DEV Community, Everyone Uses Postgres, but Why: dev.to/metis/everyone-uses-postgres-but-why-545o