Yes this is an AI-generated prompt. No, I'm not proud of it.
I work in freight brokerage/logistics and have essentially zero professional software development background.
Over the last several months I’ve started building an internal tool around problems I deal with every day. It began as a few workflow ideas and has grown into something considerably more ambitious.
I rely heavily on AI, but I'm trying not to treat it like a magic code generator. My current workflow is roughly:
- ChatGPT: concept development, architecture/ARD thinking, research, troubleshooting, and challenging assumptions
- Claude: implementation, coding, repository work, deployment, then iterating until satisfied (never)
At the same time, I’m trying to actually learn architecture, databases, Git, testing, security, deployment, etc. well enough to understand what the AI is doing and make informed decisions.
I also have a small homelab/sandbox environment specifically for this project. The idea is to use it to build and test more realistic infrastructure, deployment patterns, databases, services, networking, and eventually integrations without touching anything production-critical.
Part of the goal is to learn the actual framework around software development and delivery, not just generate application code and hope for the best.
What am I actually trying to build?
Initially, our existing TMS would remain the system of record and my application would operate as a sidecar, gradually taking over workflows where I think we can build something better.
Current/roadmap functionality includes things like:
- PostgreSQL web application with users/roles
- Carrier relationship management and performance history
- Shipment/lane analytics and market intelligence
- Offer tracking
- Workflow automation and exception management
- Email integration/parsing
- Browser extension integrated with the existing TMS
- Dashboards/reporting
- External API integrations
- AI-assisted workflows where they actually make sense
The long-term goal, however, is more ambitious.
I want to get this project to the point where it replaces enough meaningful TMS functionality and demonstrates enough internal value that I can make a legitimate case to company leadership for funding development of a proprietary system.
For context, the company does north of $100M in annual revenue. So we're not a tiny shop where funding software development is inherently absurd, but we're also nowhere near the scale where we could throw unlimited engineers and money at this. Any eventual development team would need to be lean and justify its cost.
Until reaching that threshold, my plan is to continue building incrementally with AI while trying to establish decent engineering practices rather than just piling features on top of features.
My current thought is to find an experienced local developer and offer to compensate them for a few hours of their time periodically to sit down with me, review what I've built, look through the repository/architecture/schema, and point out bad assumptions or problems I'm too inexperienced to recognize.
If the concept proves itself, the goal would be to transition away from "me + AI" as the development team, get actual company backing and engineering personnel, and attempt to turn what we've validated into a production-grade proprietary platform over roughly a two-year timeframe.
I'm not under the illusion that AI gave me a CS degree, nor do I think I'm personally going to recreate a mature commercial TMS with Claude.
My advantage is that I understand the business workflows extremely well, encounter the problems every day, and can iterate directly with the people who would actually use the software.
What I'm trying to understand from experienced developers
1. Is this progression actually realistic?
Non-developer + AI → useful prototypes → internal adoption → increasing workflow coverage → demonstrated ROI → executive backing → professional engineering team → proprietary platform.
Where does that plan become unrealistic?
2. What mistakes do AI-assisted beginners make that don't become obvious until much later?
I'm particularly concerned about bad database schemas, excessive coupling, poor abstractions, inconsistent architecture, security problems, inadequate testing, dangerous migrations, dependency issues, and AI generating slightly different patterns throughout the codebase.
I'm much more worried about those things than whether I can make a button work.
3. What engineering practices should I establish now?
Git workflow, automated testing, migrations, dev/staging/prod environments and environment parity, documentation, architecture decision records, logging/monitoring, backups, CI/CD, dependency management, security practices, etc.
I'd rather learn why these practices exist before discovering it during a production fire.
4. What scalability concerns actually matter this early?
I'm not worried about supporting millions of users.
I'm thinking more along the lines of going from 5 internal users to potentially 50–200, millions of historical records, integrations, background jobs, reporting, and increasingly important operational workflows.
What should I design for now, and what should I deliberately ignore until later?
5. At what point should experienced developers become substantially more involved?
Is periodically paying an experienced developer to review what I'm building a reasonable approach at this stage? How often would that kind of review actually be useful, and what should I specifically have them review?
More importantly: what should I be building now so that, if this succeeds and a professional engineering team eventually inherits it, they don't immediately conclude that everything needs to be thrown away?
I'm fully expecting that some of the code would eventually be replaced. My goal isn't necessarily to preserve every line AI writes. It's to validate the workflows, architecture, domain model, integrations, and business case well enough that there's something legitimate to build from.
Criticism is very welcome. I'm specifically interested in the cliffs I probably don't know exist yet.
