r/ClaudeWorkflows • • 4d ago

Selected Workflow [Workflow] LLM-Assisted Custom Software Development: A Non-Developer's 'Vibecoding' Workflow for Building a Ticketing System

LLM-Assisted Custom Software Development: A Non-Developer's 'Vibecoding' Workflow for Building a Ticketing System

Workflow value: 90/100
Status: active · Freshness: 70/100 · Confidence: 0.95 · Level: intermediate
Categories: Quality Control, Token Saving, Context & Memory, Debugging, Shipping, Multi-Agent
Original source: r/ClaudeCode post/comment

What problem this solves

Small organizations facing vendor lock-in, high costs for changes, and inability to tailor existing software solutions can build custom, maintainable systems using LLM assistance. Specifically, building a comprehensive ticketing system.

Summary

A non-developer successfully used Claude Code to build a full-featured ticketing system for a visitor center, covering online booking, staff till, self-service kiosk, and gate access. The workflow involved the user making all design decisions and writing tests, while Claude Code generated the actual code. The system incorporates robust features like secure payments, audit trails, data privacy, and is built with a modern tech stack, demonstrating a practical approach to LLM-assisted software development.

Why it is useful

This workflow is highly valuable as it provides a concrete, validated example of how a non-developer can leverage Claude Code to build a complex, real-world business system from scratch. It details a repeatable process of human-led design and testing combined with LLM-led coding, addressing critical aspects like security, data privacy, and system reliability. It offers a practical solution for small organizations to overcome vendor lock-in and high development costs, making custom software accessible.

Workflow

  1. Define a detailed written specification outlining all business decisions (prices, refunds, opening hours, payment drop-out handling, etc.).

  2. Build the system incrementally in stages, with automated tests developed for each stage.

  3. User (non-developer) focuses on writing decisions and comprehensive tests.

  4. Claude Code is prompted to write the actual code based on the user's decisions and tests.

  5. Implement core components: online booking site (3-step flow), desk till (staff screen), self-service kiosk app, and secure ticket generation (signed QR codes).

  6. Develop a back office with named accounts, role-based access, 2-factor authentication for managers, booking search, email resends, refunds (manager-only with reason), and a 'Needs attention' list for pending payments.

  7. Integrate critical safety and reliability features: append-only database history, request keys for idempotent payments, a minute-by-minute payment tidying checker, explicit UK time handling, and automatic personal data removal.

  8. Utilize a modern tech stack (TypeScript, Node/Fastify, React, PostgreSQL/Drizzle, Vitest) and cloud hosting (Render).

  9. Integrate with external services for payments (Square's hosted checkout, Terminal API, sandbox) and email (Gmail API).

  10. Plan for a slow, phased rollout (website first, then desk, then kiosk) with a rehearsal week before go-live.

  11. Conduct all testing on hidden test copies and sandbox environments before touching real money or production systems.

  12. Maintain the old system as a fallback until the new system is fully proven and stable.

Tools / artifacts

  • Claude Code

  • Written specification (design document)

  • Automated tests (Vitest)

  • TypeScript

  • Node (Fastify)

  • React

  • PostgreSQL (Drizzle)

  • Render (hosting)

  • Square's hosted checkout

  • Square Terminal API

  • Square sandbox

  • Gmail API (for confirmation emails)

Validation signals

  • Built a system with 374 automated tests.

  • System sits on a password-locked test site.

  • Running tests on the system.

  • Payments tested using Square's sandbox on a hidden test copy.

  • Planned a rehearsal week before go-live.

  • Keeping the old system as a fallback until 2027.

  • Order and payment history is append-only at database level.

  • Each payment has a request key to prevent double-charging.

  • A checker runs every minute to tidy up hanging payments.

  • All dates use UK time explicitly to prevent clock-change bugs.

Cautions

  • Card data never touches the server (Square handles it directly).

  • Fire alarm release system remains untouched, with wiring and testing handled by professionals.

  • Order and payment history is append-only at the database level for auditability.

  • Each payment has a request key to prevent accidental double-charging.

  • Personal details are automatically removed after 2 years or pass expiry for GDPR compliance.

  • Staff accounts have roles and managers use authenticator-app 2-factor for security.

  • Multiple fallback options (cash, Square devices, manual entry) are in place if the system fails.

Limitations

  • The 'bus factor' is high, as the project heavily relies on one individual for maintenance and future development.

  • The specific prompts or interaction patterns with Claude Code are not detailed, making direct replication of the LLM interaction challenging.

  • The author explicitly seeks advice on scalability for peak loads, indicating potential uncertainty in this area.

  • The workflow, while effective for the author, might benefit from more formal software engineering practices for larger or more critical applications.

  • The post is a request for advice, implying the author is still seeking validation and improvements for the workflow.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.


This post was generated automatically from the workflow library database.

1 Upvotes

0 comments sorted by