DEV Community: Mihir Shaik

Building Fast with Claude Code Is Easy. Securing the App Is the Hard Part

Mihir Shaik — Tue, 04 Aug 2026 22:23:42 +0000

Disclosure

Full disclosure: I currently intern at Perfai Security, the authorization and access control testing platform mentioned later in this article. This isn't a sponsored post—I genuinely built FlashDraft as a personal project, and because I work at Perfai, I naturally used it as part of my release process. If you think either the app or Perfai could be improved, I'd genuinely appreciate your honest feedback.

The Problem

AI coding tools make it possible to generate dashboards, databases, authentication flows, and API routes faster than ever.

But a working application is not automatically a secure application.

This becomes especially important when an app has multiple users, private data, ownership rules, and different permission levels. A user may be signed in correctly but still gain access to another user's information or perform actions they should not be allowed to perform.

I wanted to explore both sides of AI-assisted development: how quickly I could build a real multi-user application and how I could verify its authorization before calling it complete.

Using Claude Code, I built FlashDraft, a one-week fantasy soccer platform with league commissioners, members, site administrators, private draft boards, trades, rosters, and league-specific controls.

This article is less about the fantasy game itself and more about what I learned while building quickly with AI, defining permissions, and testing the deployed application for authorization problems.

The Project

FlashDraft is a short-format fantasy soccer application where users create leagues, draft players, manage rosters, and compete for one week.

The application has three main roles:

Site administrators manage the overall platform.
League commissioners manage the leagues they create.
League members manage their own teams, lineups, trades, and private draft information.

These roles created the main technical challenge.

Authentication could confirm who a user was, but the application still needed to determine which leagues, teams, settings, and actions that user was authorized to access.

For example, a member should be able to edit their own lineup but not another member's lineup. A commissioner should be able to manage their own league but not a league created by someone else. A private draft board should remain private even from other members in the same league.

Those permission boundaries became one of the most important parts of the project.

Dashboard:

We can see the player list as well, along with their prices:

Tech Stack

FlashDraft was built using:

Claude Code
TypeScript
Prisma ORM
PostgreSQL
Tailwind CSS
Clerk Authentication
Neon Database
Vercel

Claude Code generated much of the application's foundation, including:

Database models
Dashboards
API routes
League workflows
Authentication flows

Clerk handled authentication, while Prisma and Neon managed users, leagues, rosters, trades, draft selections, and league settings.

Testing the Authorization Model

Building an application that works is only half the challenge.

FlashDraft stores user accounts, league memberships, team ownership, private draft strategies, trades, lineups, and league settings. If authorization is implemented incorrectly, one user could potentially view or modify information belonging to someone else.

I began by testing the application manually with multiple accounts, roles, and leagues.

I checked whether:

A member could access another member's team
A member could edit another user's lineup
A commissioner could manage a league they did not create
A non-member could access a private league
One user could view another user's private draft board
A user could manipulate IDs inside requests
Sensitive API responses exposed unnecessary data
Admin and commissioner permissions remained separate

This type of testing is important because normal user flows only confirm that allowed actions work. Authorization testing also asks whether forbidden actions are properly blocked.

After completing the manual checks, I submitted the deployed application to Perfai Security.

Perfai tested the running application's authorization and access-control behavior. The goal was not simply to review whether the code looked correct. It was to validate whether users could access only the resources and actions they were permitted to use.

This mattered because authorization bugs often appear across the boundaries between users, roles, resources, and API endpoints.

No automated tool can guarantee that an application is completely secure. However, testing the deployed product can help identify access-control weaknesses that may be missed during rapid AI-assisted development.

Because I currently intern at Perfai Security, I naturally used it as part of my release process. Readers can view the demo or create an account using the links near the end of this article.

All I needed to do was submit my live link, and Perfai Security did the rest.

How I Built It with Claude Code

FlashDraft began as a detailed product prompt inside Claude Code.

I first defined the main roles, resources, and workflows. These included users, leagues, teams, rosters, drafts, trades, league settings, and private draft boards.

Claude Code then helped generate much of the application foundation, including:

Database models
Prisma relationships
Authentication flows
API routes
Dashboards
League workflows
UI components

This dramatically reduced the time required to create boilerplate and connect the major parts of the application.

However, generating the structure was only the beginning.

I still needed to decide who owned each resource, which roles could perform each action, and where authorization needed to be enforced on the server.

AI was effective at producing code quickly, but it could not replace the product decisions behind the permission model.

A useful way to think about the process was:

The biggest lesson was that AI-generated code should be treated as a strong first draft, not automatically trusted as production-ready.

Authentication Is Not Authorization

One of the most important lessons from this project was the difference between authentication and authorization.

Authentication answers: Who is the user?

Authorization answers: What is that user allowed to do?

Clerk handled authentication by identifying signed-in users.

The application still needed server-side checks to confirm:

Whether the user belonged to the requested league
Whether the user owned the requested team
Whether the user was the commissioner of that league
Whether the user could edit a roster or lineup
Whether the user could view a private draft board
Whether the user could approve a trade
Whether the requested resource belonged to another user

A route is not secure simply because it checks that someone is logged in.

Every sensitive request must also verify that the authenticated user has permission to access the specific resource or action.

What I Learned

By the end of the project, FlashDraft included public and private leagues, live drafts, salary-cap roster building, trades, commissioner controls, private draft boards, persistent data, and a public deployment.

The more important result, however, was the development process.

Claude Code made it possible to move from an idea to a functional application extremely quickly. But speed did not remove the need to:

Define roles before generating routes
Decide who owns each resource
Enforce permissions on the server
Test with multiple accounts
Attempt actions users should not be allowed to perform
Review API responses for private-data exposure
Test the deployed application rather than only local code

AI made building faster.

It did not make authorization automatic.

Lessons for Vibe Coders

The biggest lesson from FlashDraft is that a functioning interface can create a false sense of completion.

An application may look polished, authenticate users correctly, and support all its intended workflows while still containing serious authorization problems.

For anyone building with Claude Code or another AI coding tool, I would recommend:

Define every user role before generating the application.
List the resources each role can view, create, edit, or delete.
Never rely on hidden buttons as a security control.
Validate ownership and permissions on the server.
Test the application with multiple users and multiple organizations or groups.
Try changing IDs, URLs, and request values.
Check whether API responses expose private information.
Treat generated code as a first draft.
Test the deployed application before release.
Make security checks part of the normal build process.

AI-assisted development makes it easier to turn ideas into software.

The next challenge is making sure the software behaves correctly when users attempt actions they were never supposed to perform.

Try the Project and Security Tools

Play FlashDraft

Try the live application: https://worldcupfantasy-seven.vercel.app/

I would especially appreciate feedback on the gameplay, user experience, one-week league format, and any bugs you encounter.

Test Your Vibe-Coded App with Perfai Security

https://perfai.ai

Join the Discussion

I would love to hear from other vibe coders and developers.

Leave your feedback in the comments. I will read every response and reply thoughtfully to each one.

I Built a Calendar App Kids Control — Even Parents Can't Access It

Mihir Shaik — Tue, 28 Jul 2026 17:33:49 +0000

Over one session, I built Kid Compass — a calendar and chore planner designed so kids plan their own day, and parents can only watch, suggest, and cheer, never edit. It's a small, human idea wrapped around one of the trickiest authorization shapes in this whole series: a privacy boundary that holds even against the account that's paying for the app, managing the family, and has every other administrative power available.

Unlike the previous builds in this series, this one didn't start from a single spec-in-one-prompt. It started as a brainstorm — a long list of possible authorization-testing app ideas, narrowed down over a few rounds of conversation, before landing on a specific pedagogical goal: an app that promotes independence in kids, not surveillance of them. That shift in framing — from "parent controls the calendar" to "kid owns the calendar, parent is a guest" — is what produced the interesting access-control problem underneath it.

About Kid Compass

Kid Compass is a role-based family planner built around four types of users:

• Family Admin — the parent who set up the household
• Guardian — a co-parent with full standing access
• Secondary Guardian — a babysitter, grandparent, or coach with narrowly scoped access
• Child — the owner of their own day

Family Admins and Guardians can:

• See every child's schedule, chores, and tasks in the family
• Leave a suggestion (a comment or nudge) on any block or task
• Assign a chore to a specific child, or drop it into a shared pool for any kid to claim
• Set a reward on a chore
• Turn on "maturity mode" for a child, unlocking their ability to mark entries private

Secondary Guardians can:

• See only what an explicit, revocable grant allows — one child, optionally one kind of entry, optionally a bounded time window

Children can:

• Create, edit, and delete their own schedule blocks and tasks
• Mark an entry private, if maturity mode is on for them
• Claim an unclaimed chore from the family pool
• Mark their own tasks complete — and only their own

I wanted this one to have a different shape than "owner vs. everyone else" or "time-gated reveal," which I'd already built. Here the interesting boundary is: two people can hold the exact same role (two kids are both CHILD) and still need to be fully isolated from each other, and one field on a single database row can have two different owners depending on who's writing to it — the child owns the title, the parent owns the reward.

My Tech Stack

• Claude Code
• TypeScript
• Next.js (App Router)
• React
• Tailwind CSS
• Radix-based shadcn/ui components
• Clerk Authentication
• PostgreSQL
• Prisma ORM
• Neon Database
• Vercel
• PerfAI Security (free access control testing)

Same stack as the rest of the series, pinned to the same dependency versions as the earlier sibling apps for consistency.

Development Process

After settling on the concept, I used Claude Code to build the application in a single development session. The project included user authentication, role-based permissions, family management, dashboards for parents and children, scheduling features, chores, rewards, and a complete authorization system.

As with every project in this series, the first version wasn't the final version. I refined several authorization edge cases, improved the user experience, fixed UI inconsistencies, and prepared the application for security testing before considering the project complete.

The result was a fully functional application that demonstrates how modern AI development tools can dramatically accelerate building complex software while still requiring thoughtful review, iteration, and security validation.

Try Kid Compass

Kid Compass is live at kid-compass-teal.vercel.app. There's a live demo at /demo that drops you straight into a real family's week — activities, chores with rewards, a shared chore pool, and one entry that stays private even from the parents watching — no account needed to look around.

Security Check with PerfAI

Kid Compass manages sensitive family information, including children's schedules, private calendar entries, chores, rewards, and delegated guardian permissions. Applications like this require much more than simple authentication — they require carefully enforced authorization to ensure every user can only access the information they're supposed to see.

To validate these authorization rules, I reviewed the application using PerfAI Security, focusing on the areas most likely to expose sensitive family data.

The review evaluated questions such as:

• Can one child access another child's private schedule?
• Can a guardian modify information they're only supposed to view?
• Can delegated guardians access data outside their assigned permissions?
• Are private calendar entries properly protected?
• Are ownership checks enforced across every API request?

The review identified several authorization improvements involving delegated permissions, ownership validation, and response filtering. After implementing these recommendations, the application's authorization model became significantly stronger and better protected against common access-control vulnerabilities.

All I needed to do was type in my app's URL.

Final Takeaway

Kid Compass explored a different kind of authorization problem than the other applications in this series.

Instead of asking whether a user could access another person's resources based on role alone, the application required permissions to depend on family relationships, delegated access, ownership of individual pieces of data, and even ownership of specific fields within the same database record.

Claude Code accelerated the development process and helped build a complex permission model in a single session, while PerfAI Security helped validate the authorization boundaries that protect children's privacy and family data.

The combination of AI-assisted development and authorization testing produced a much stronger foundation before release and reinforced an important lesson from this series: the most difficult security problems usually aren't about authentication — they're about correctly enforcing who should be allowed to access what, under exactly which conditions.

App URL: https://kid-compass-teal.vercel.app