Case Study 1: From Capstone to Startup

How a Graduate's AI-Built Project Became a Real Business

The Scenario

In May 2025, Priya Chandrasekaran was finishing her computer science degree at a mid-size university in the Pacific Northwest. Like every student in her program, she needed to complete a capstone project demonstrating mastery of software engineering principles. Unlike most of her classmates, Priya had spent the previous eight months teaching herself vibe coding -- building software through structured collaboration with AI coding assistants. Her capstone project, which she called ShiftSync, would become the foundation of a real business within six months.

ShiftSync is a workforce scheduling platform designed for small restaurants and retail shops. The problem it solves is specific and painful: managers at restaurants with 10 to 40 employees spend hours every week building shift schedules manually, juggling employee availability, labor law compliance, overtime limits, and last-minute shift swaps. Existing enterprise solutions like When I Work and Deputy cost $4 to $8 per employee per month and are designed for large organizations. Small businesses with tight margins often resort to spreadsheets and group text messages.

Priya knew the problem firsthand. Her parents ran a Vietnamese restaurant with 16 employees, and she had watched her mother spend Sunday evenings building the week's schedule in a spreadsheet, cross-referencing availability texts from each employee, checking that minors were not scheduled past 10 PM, and ensuring no one exceeded 40 hours. It was a two-hour process that happened every single week.

This case study traces ShiftSync from capstone project to funded startup, examining how vibe coding made the journey possible.

Phase 1: Specification and Requirements (Week 1)

Priya began not by writing code but by writing requirements. Drawing on the specification-driven approach from Chapter 10, she spent the first week interviewing five small business owners (including her mother) to understand their scheduling pain points. She synthesized the interviews into a structured requirements document.

Core User Stories:

1. As a manager, I can create a weekly schedule by dragging employees into time slots on a visual grid, so that scheduling takes minutes instead of hours.
2. As an employee, I can submit my weekly availability through a mobile-friendly form, so the manager knows when I can work.
3. As a manager, I can see conflicts (overtime violations, unavailable employees, minor labor restrictions) highlighted in real-time as I build the schedule, so I do not create illegal or problematic schedules.
4. As an employee, I can request a shift swap with a coworker, and the manager can approve or deny the swap with one click.
5. As a manager, I can publish the schedule and all employees receive a notification with their shifts for the week.

Technical Constraints:

• Mobile-first design (most employees check schedules on their phones)
• Must handle time zones correctly (some businesses have employees in adjacent time zones)
• Must enforce configurable labor rules (different states have different rules for minors, overtime, and required breaks)
• Must work offline for employees with unreliable connectivity (Progressive Web App)

Subscription Model:

• Free tier: 1 location, up to 10 employees, basic scheduling
• Pro tier ($29/month): Unlimited employees, shift swap requests, labor compliance engine, schedule templates
• Enterprise tier ($79/month): Multiple locations, reporting, API access, priority support

Priya noted that the specification alone -- before any code was written -- took about 15 hours. She later reflected that this was the most important phase of the entire project. Every design decision she made subsequently was informed by those five interviews and the structured requirements they produced.

Lesson: Priya's approach demonstrates a principle that recurs throughout this book: the time spent on requirements is never wasted. AI assistants can generate code in seconds, but they cannot generate correct requirements. The human's job is to ensure the right thing gets built; the AI's job is to build it efficiently.

Phase 2: Architecture Decisions (Week 2)

With requirements in hand, Priya made her architecture decisions. She chose a stack similar to TaskFlow's (Section 41.2) but with modifications for her specific needs:

• Backend: FastAPI with SQLAlchemy and PostgreSQL, because she was comfortable with Python and needed async support for real-time schedule updates.
• Frontend: React with TypeScript and Tailwind CSS, rendered as a Progressive Web App for mobile access and offline support.
• Real-time updates: WebSockets via FastAPI's built-in WebSocket support, so schedule changes appear instantly for all users viewing the same schedule.
• Labor compliance engine: A rule engine built in Python that evaluates configurable rules (JSON format) against schedule drafts. Each state's rules are defined as a JSON configuration file, making it easy to add new jurisdictions without code changes.

The architecture decision she later identified as most critical was the labor compliance engine. Rather than hard-coding labor rules, she designed a declarative rule format:

{
  "jurisdiction": "WA",
  "rules": [
    {
      "id": "minor_hours",
      "description": "Minors (under 18) cannot work more than 4 hours on a school day",
      "condition": "employee.age < 18 AND day.is_school_day",
      "constraint": "shift.duration_hours <= 4",
      "severity": "error"
    },
    {
      "id": "overtime_warning",
      "description": "Warn when an employee approaches 40 hours in a week",
      "condition": "employee.weekly_hours + shift.duration_hours > 36",
      "constraint": "employee.weekly_hours + shift.duration_hours <= 40",
      "severity": "warning"
    }
  ]
}

This declarative approach meant that adding support for a new state's labor laws required only a new JSON file, not code changes. The pattern is directly analogous to DataLens's YAML pipeline configuration (Section 41.6) -- separating the "what" from the "how."

Phase 3: Implementation with Vibe Coding (Weeks 3-8)

Priya's implementation phase lasted six weeks. She worked roughly 25 hours per week on the project, of which she estimated about 30% was writing prompts and reviewing AI output, 20% was manual coding for integration logic and edge cases, 20% was testing, and 30% was debugging and refinement.

Week 3: Authentication and User Management. Using the same phased approach described in Section 41.3, Priya started with authentication. Her prompt was specific about security requirements:

Implement JWT-based authentication for a FastAPI application. Include:
registration with email/password, login returning access and refresh tokens,
bcrypt password hashing, rate limiting on login attempts (5 per minute per IP),
and role-based access (manager, employee). Managers can invite employees
via email. Include Pydantic schemas for all endpoints and comprehensive
pytest tests.

The AI generated approximately 400 lines of code covering the auth system. Priya reviewed every line, catching one issue: the rate limiter was per-user rather than per-IP, which would not prevent brute-force attacks against unknown accounts. She filed this in her notes and asked the AI to fix it with a follow-up prompt. This interaction -- generate, review, refine -- became her standard workflow.

Weeks 4-5: Core Scheduling Engine. The scheduling grid was the most complex component. Priya broke it into three prompts:

1. A data model for schedules, shifts, and employee availability (backend).
2. A React component for the visual scheduling grid with drag-and-drop (frontend).
3. WebSocket integration for real-time updates when multiple managers view the same schedule.

The drag-and-drop grid required the most iteration. The initial AI-generated component used react-beautiful-dnd, but it did not handle the specific constraint that a single employee could not be in two shifts at the same time. Priya needed three rounds of refinement (Chapter 11's iterative approach) to get the collision detection working correctly.

Week 6: Labor Compliance Engine. The compliance engine was where Priya's declarative design paid off. She prompted the AI to build a rule evaluator that parsed the JSON rule format and evaluated each rule against a proposed schedule change. The AI generated a clean implementation using Python's operator module for comparisons and a simple expression parser for conditions. Priya extended it manually to handle compound conditions (AND/OR) and to collect all violations rather than stopping at the first one.

Weeks 7-8: Shift Swaps, Notifications, and Polish. The remaining features -- shift swap requests, push notifications via web push API, and UI polish -- came together more quickly because the foundations were solid. Priya noted that later prompts were much more effective because she could reference existing code: "Add a shift swap request model that references the existing Shift model and uses the same notification dispatch pattern as the schedule publication feature."

Phase 4: Testing (Throughout, but Focused in Week 7)

Priya maintained tests throughout development, but dedicated most of Week 7 to closing coverage gaps. Her final test suite included:

• 87 unit tests for the backend, covering the compliance engine (42 tests for various rule combinations), authentication (18 tests), and scheduling logic (27 tests).
• 23 integration tests for API endpoints, using a test database with fixtures for a complete restaurant setup (manager, 12 employees, availability records, existing schedule).
• 11 end-to-end tests using Playwright, covering the critical flows: login, create schedule, drag-and-drop shift assignment, detect compliance violation, request shift swap, approve swap.

The compliance engine tests were the most valuable. Priya created test fixtures for each labor rule and verified that the engine correctly flagged violations. One test revealed that the overtime calculation did not account for shifts that spanned midnight (a 10 PM to 2 AM shift was counted as negative hours). She caught this only because she had written a specific test for overnight shifts -- a reminder that AI-generated code benefits enormously from human-designed test cases that probe edge cases the AI might not consider.

Phase 5: The Capstone Presentation

Priya presented ShiftSync to her capstone committee in May 2025. The demo included:

1. A manager creating a weekly schedule for a restaurant with 16 employees.
2. The compliance engine flagging that a 17-year-old was scheduled for a 6-hour shift on a school day (Washington state limits minors to 4 hours on school days).
3. An employee requesting a shift swap on their phone (Progressive Web App).
4. The manager approving the swap and all affected employees receiving notifications.

The committee was impressed by the scope and polish. One professor asked how she had built so much in eight weeks. Priya explained her vibe coding workflow: structured prompts, iterative refinement, comprehensive testing, and careful architecture decisions upfront. She emphasized that the AI had not reduced the intellectual difficulty of the project -- she still had to make every design decision -- but it had dramatically reduced the implementation time.

She received an A on the capstone and graduated with honors.

Phase 6: From Capstone to Product (Summer 2025)

What happened next was not part of the academic plan. In June, Priya deployed ShiftSync to a $5/month VPS and let her mother use it at the restaurant. Within two weeks, three other restaurant owners in the same shopping plaza asked if they could use it. By July, Priya had 8 businesses using the free tier.

The transition from capstone to product required changes that the academic project had not addressed:

Multi-tenancy. The capstone version used a single database. Priya refactored to add organization-level data isolation, using the same approach described in Exercise 25 of this chapter: PostgreSQL Row-Level Security policies that scope every query to the current organization.

Stripe integration. She added subscription billing, closely following the TaskFlow pattern from Section 41.3. The Stripe integration took three days with AI assistance -- she reflected that it would have taken at least two weeks without it, because Stripe's webhook lifecycle has many edge cases.

Mobile optimization. She spent a full week improving the mobile experience based on feedback from employees who used the app primarily on older Android phones. The AI helped her optimize the React components for performance, but the design decisions about what information to show on a small screen required human judgment about user priorities.

Compliance rule expansion. She added labor rules for Oregon and California. Each state took about two hours because her declarative rule format meant she only needed to write JSON, not code. California's meal break requirements were the most complex, requiring a new rule type that checked for breaks within continuous work periods.

Phase 7: Funding and Growth (Fall 2025 - Winter 2026)

By September 2025, ShiftSync had 35 paying customers (all on the Pro tier at $29/month) and about $1,000 in monthly recurring revenue. Priya applied to a local startup accelerator and was accepted.

The accelerator's technical mentors were initially skeptical of a solo developer building a product of this complexity. When Priya demonstrated her development workflow -- showing how she used AI to generate and iterate on code while maintaining comprehensive test coverage and clean architecture -- the skepticism turned to interest. Several mentors noted that her codebase was better structured than projects built by teams of three or four developers.

In November 2025, Priya raised a $150,000 pre-seed round from two angel investors. The pitch was straightforward: small restaurants and retail shops represent a massive underserved market, ShiftSync is 80% cheaper than existing enterprise solutions, the compliance engine is a defensible differentiator, and the AI-assisted development approach means a solo developer can iterate at the speed of a small team.

By February 2026, ShiftSync has 142 paying customers, $4,300 in monthly recurring revenue, and supports labor law compliance for 12 U.S. states. Priya has hired one part-time contractor (also a vibe coder) to help with frontend development.

Lessons Learned

Priya's journey from capstone to startup illustrates several principles that apply broadly to vibe coding at scale.

1. Domain knowledge is the irreplaceable ingredient. Priya built ShiftSync because she understood restaurant scheduling deeply from personal experience. The AI could generate a scheduling grid, but it could not tell her that overnight shifts need special handling, that minors have different rules on school days versus weekends, or that managers prefer to see the whole week at once rather than one day at a time. Domain knowledge shaped every prompt she wrote.

2. The declarative rule engine was the best architecture decision. By separating labor rules from code, Priya made it possible to expand to new states without engineering effort. This decision -- made in Week 2, before any code was written -- was worth more than any individual feature. It is a direct application of the principle from Section 41.10: architecture decisions matter more than code quality.

3. Vibe coding does not eliminate the need for deep testing. The overnight shift bug would have caused real legal liability for a restaurant. It was caught not by the AI but by a human who thought to test edge cases involving midnight crossings. AI-generated tests tend to cover happy paths; human-designed tests probe the boundaries where bugs hide.

4. The capstone-to-product gap is smaller than expected. The main additions -- multi-tenancy, payment processing, mobile optimization -- were substantial but well-understood problems with clear patterns (many described in this book). Priya estimated that AI assistance reduced the capstone-to-product transition from six months of full-time work to three months of part-time work.

5. Investors value execution speed as much as the product. The fact that Priya could iterate on features, respond to customer feedback, and expand compliance coverage rapidly -- as a solo developer -- was itself a competitive advantage. The AI-assisted workflow was not just a development tool; it was part of the business strategy.

Reflection: What Could Have Gone Wrong

Not every capstone project becomes a startup, and Priya's success involved favorable circumstances. But examining what could have gone wrong is instructive.

If she had skipped the requirements phase and jumped straight to coding, the product might have been technically impressive but misaligned with what restaurant managers actually need. Several features she initially planned (employee skill matching, AI-powered schedule optimization) were cut during requirements gathering because the restaurant owners said they were not useful. Knowing what to cut saved weeks of development time.

If she had chosen a more complex architecture (microservices, event sourcing, or a separate mobile app instead of a PWA), the maintenance burden would have overwhelmed a solo developer. The monolithic architecture, often dismissed as unsophisticated, was exactly right for a product with fewer than 200 customers.

If she had not invested in testing, the compliance engine bugs would have surfaced in production, potentially causing legal issues for her customers. For a product that enforces labor law compliance, correctness is not a nice-to-have -- it is a legal requirement.

These potential failure modes all trace back to human judgment rather than AI capability. The AI could have built any of the discarded features, maintained a microservices architecture, or shipped without tests. It was Priya's decisions -- informed by domain knowledge, architecture principles, and testing discipline -- that kept the project on track.

Key Metrics

This case study is a composite based on real patterns observed in student projects and early-stage startups. Names and specific details have been fictionalized, but the development timeline, technical decisions, and business trajectory reflect authentic experiences reported by developers using AI-assisted workflows to build production software.