DEV Community: Sidharth Sangelia

I'm Rebuilding My Old Invoice App and This Time I Actually Know What I'm Doing

Sidharth Sangelia — Sun, 19 Apr 2026 19:12:33 +0000

So I have this old project called Invoicepedia. Built it like 6 months ago when I was just starting to learn full stack. Next.js, Clerk, Neon, basic CRUD. The usual "I just learned how to connect a database" kind of project.

I opened it recently and honestly it was rough. Delete button crashed the app sometimes. You could submit an empty invoice form with no validation. The Stripe integration was half working. I had both Drizzle and Prisma installed at the same time for some reason. Classic.

I almost deleted it and moved on to something new.

Instead I decided to actually fix it and turn it into something real.

Why Not Just Start a New Project

Every time I start something new I spend like 3-4 days just on setup. Auth, database, environment variables, middleware, all that stuff before you even write a single line of actual product code. And by the time I'm done with setup I've already lost interest or I hit some weird error and just abandon the whole thing.

Invoicepedia already had all of that. It was broken but the foundation was there. Auth worked. Database was connected. Routes existed.

So I thought okay, why not just fix this one instead of starting from zero again. Worst case I learn something. Best case I actually ship something.

First Thing I Did Was Stop Adding Features

Old me would have immediately started adding new stuff. Charts. Dark mode. AI features. Whatever sounded cool.

This time I made a list of everything that was broken and fixed that first. No new features until the existing stuff actually worked properly.

Removed dead dependencies. Rewrote the schema. Added proper Zod validation to every server action. Changed hard deletes to soft deletes because you should never hard delete financial records. Fixed the middleware. Added actual error handling.

It took a week and nothing visually changed. The app looked the same. But after that week I wasn't scared to touch the codebase anymore and that felt different.

What I'm Actually Trying to Build

Yeah I know. Another invoice app. There's like 50 of them already.

But here's the thing — most of them are either too expensive or too complicated for a normal freelancer. FreshBooks charges you $19-30 a month and limits your clients on the cheaper plans. Wave was free and then slowly started charging for things that used to be free. Invoice Ninja has so many features that the UI looks like a cockpit, a normal person opens it and immediately closes the tab.

The people I want to use this are freelancers. Developers, designers, writers. People who just did some work, need to send an invoice, and want to get paid without learning accounting software.

So the whole idea is just — do the basic things really well. Don't try to be QuickBooks. Don't try to be FreshBooks. Just be the thing a freelancer needs to send professional invoices and track who's paid them and who hasn't.

What I'm Shipping First

I made a list of like 10 features I want to build eventually. AI invoice generation, automated payment reminders, client portal, recurring invoices, expense tracking. The full thing.

Then I looked at that list and realised if I wait until all of that is done I will never ship anything.

So the first version is going to have three things:

PDF generation — because an invoice app that can't produce a PDF is just a form.

Email sending — so you can actually send the invoice to your client from inside the app instead of downloading it and attaching it to Gmail manually.

A proper dashboard — right now it's just a table. I'm adding three metric cards at the top so when you open the app you see immediately how much you got paid this month, how much is still outstanding, and how many invoices are overdue. That's actually useful information.

That's it. Ship those three. Get some users. See what they actually want next.

The Goal is 5 Users

Not 500. Not 5000. Five real people who use it and tell me what's wrong with it.

I'll post updates as I build. What I'm adding, what's breaking, what people say when they actually try it. I don't have it all figured out, I'm figuring it out as I go.

If you're a freelancer who's annoyed at paying too much for invoicing software, keep an eye on this. If you're a dev learning full stack, hopefully this is useful to see what an actual messy in-progress project looks like compared to the clean tutorial versions.

Stack is Next.js 15, Prisma, NeonDB, Clerk, Tailwind, shadcn/ui.

Happy to answer questions in the comments if anything here was interesting or you want to know more about specific decisions I made.

HTTP Status Codes: A Developer's Real-World Guide🚦

Sidharth Sangelia — Wed, 03 Sep 2025 16:46:18 +0000

Hey fellow developers! 👋

Last week, I spent three hours debugging what I thought was a complex authentication issue, only to discover it was a simple 422 error that I completely misunderstood. That frustrating evening made me realize how many of us know the "famous" status codes (hello, 404!) but struggle with the nuanced ones that could save us hours of debugging.

So here's my attempt to break down HTTP status codes in a way that actually sticks. No dry documentation here – just real scenarios we face every day.

Wait, Why Should I Care About Status Codes?

Before we dive in, let me tell you why this matters. Last month, our API was returning 200 OK for failed operations (yeah, I know...), and our frontend team was going crazy trying to figure out why their error handling wasn't working. The fix? Proper status codes. It's not just about following standards – it's about making your life and your team's life easier.

The Categories That Actually Matter

2xx - The "Everything's Fine" Family ✅

200 OK - The Reliable FriendThis is your bread and butter. GET request for user data? 200. Successful login? 200. But here's the thing – don't use 200 for everything just because it works.

// Good use of 200
GET /api/users/123
Response: 200 OK with user data

// Bad use of 200 
POST /api/users (creating a user)
Response: 200 OK // Should be 201!

201 Created - The OverachieverI used to ignore this one until I realized how much cleaner my API responses became. Use 201 when you've successfully created something new. Your frontend developers will thank you because they can differentiate between "I got existing data" and "I just created something new."

// Perfect 201 usage
POST /api/posts
{
  "title": "My awesome post",
  "content": "Some content here"
}
Response: 201 Created
{
  "id": 456,
  "title": "My awesome post",
  "created_at": "2024-01-15T10:30:00Z"
}

204 No Content - The Strong Silent TypeThis one's beautiful for DELETE operations and updates where you don't need to send data back. Clean, efficient, and tells the client "job done, nothing more to say."

// Elegant 204 usage
DELETE /api/users/123
Response: 204 No Content
// No response body needed - the status says it all

3xx - The "Look Elsewhere" Family 🔄

301 vs 302 - The Redirect SiblingsThese two confused me for years. Here's how I remember them:

301: "This moved permanently, update your bookmarks" (like when you change your domain)
302: "This moved temporarily, keep using the old URL" (like maintenance pages)

Real talk: Most of the time you'll use 301 for SEO-friendly redirects and 302 for temporary stuff.

304 Not Modified - The Bandwidth SaverThis little gem enables caching magic. When implemented correctly, it can dramatically speed up your app. The client asks "has this changed since last time?" and you respond "nope, use your cached version."

4xx - The "You Messed Up" Family ❌

400 Bad Request - The Vague ComplainerThis is the generic "something's wrong with your request" response. But here's a pro tip: always include helpful error messages in the response body.

// Bad 400 response
Response: 400 Bad Request
"Invalid request"

// Good 400 response
Response: 400 Bad Request
{
  "error": "Validation failed",
  "details": {
    "email": "Email format is invalid",
    "password": "Password must be at least 8 characters"
  }
}

401 vs 403 - The Permission PoliceThis distinction trips up so many developers:

401 Unauthorized: "Who are you? Please log in."
403 Forbidden: "I know who you are, but you can't do this."

Think of 401 as a bouncer asking for ID, and 403 as the same bouncer saying "sorry, members only."

404 Not Found - The CelebrityEveryone knows this one, but here's something interesting: sometimes returning 404 is a security feature. Instead of returning 403 for a private resource (which tells attackers it exists), return 404 to keep things secret.

422 Unprocessable Entity - The PerfectionistThis one saved my sanity. Use 422 when the request is well-formed but semantically incorrect. Like when someone submits a perfectly formatted JSON with an email that passes regex validation but the domain doesn't exist.

// 422 vs 400 example
POST /api/users
{
  "email": "user@fakemaindomain.com", // Valid format, fake domain
  "age": -5 // Semantically wrong
}
Response: 422 Unprocessable Entity
{
  "error": "Invalid user data",
  "details": {
    "email": "Domain does not exist",
    "age": "Age cannot be negative"
  }
}

5xx - The "I Messed Up" Family 💥

500 Internal Server Error - The NightmareThe universal "something went wrong on our end." Never let your users see these in production without proper error handling and logging.

502 Bad Gateway - The Middleman ProblemThis usually means your server is trying to talk to another server (database, external API, microservice) and that conversation failed. Super common with microservices architecture.

503 Service Unavailable - The Planned OutagePerfect for maintenance windows. Include a Retry-After header to tell clients when to try again.

The Debugging Stories You'll Relate To

The Case of the Mysterious 502

Last month, our checkout process started throwing 502s randomly. Turns out, our payment service was timing out, but our API gateway was returning 502 instead of 504. The fix? Proper timeout configuration and using 504 (Gateway Timeout) for actual timeout scenarios.

The 200 That Lied

We had a "successful" user creation endpoint that always returned 200 OK, even when the email already existed. The frontend team was showing success messages for failed registrations. The lesson? Don't be afraid to use 409 (Conflict) for duplicate resources.

The Authentication Maze

Our mobile app was stuck in redirect loops because we were using 302 for OAuth redirects. Mobile apps don't handle redirects the same way browsers do. Switch to proper API responses with tokens instead of relying on redirects.

Status Codes in the Real World

REST API Best Practices

// User Management API
GET    /api/users     → 200 (list of users)
POST   /api/users     → 201 (user created)
GET    /api/users/123 → 200 (user found) or 404 (not found)
PUT    /api/users/123 → 200 (updated) or 404 (not found)
DELETE /api/users/123 → 204 (deleted) or 404 (not found)

Error Handling Patterns

// Frontend error handling
fetch('/api/users', {
  method: 'POST',
  body: JSON.stringify(userData)
})
.then(response => {
  if (response.status === 201) {
    showSuccess('User created successfully!');
  } else if (response.status === 422) {
    return response.json().then(errors => {
      showValidationErrors(errors.details);
    });
  } else if (response.status === 409) {
    showError('User already exists');
  }
})
.catch(error => {
  showError('Something went wrong. Please try again.');
});

The Tools That'll Save Your Sanity

Browser DevTools

Your best friend for debugging. The Network tab shows status codes for every request. Pro tip: right-click and "Copy as cURL" to test APIs directly.

Postman/Insomnia

Perfect for API testing. Set up collections with different scenarios and expected status codes.

curl Commands

# Check just the status code
curl -I https://api.example.com/users

# Follow redirects
curl -L https://example.com/old-url

# Show response headers and status
curl -v https://api.example.com/users

The Quirky Ones Worth Knowing

418 I'm a Teapot ☕Started as an April Fools' joke but is now used by some APIs to detect automated requests. Some developers use it for rate limiting with a sense of humor.

451 Unavailable for Legal ReasonsNamed after the book "Fahrenheit 451," used when content is blocked due to legal restrictions. More relevant than ever in our current internet landscape.

Common Pitfalls I've Seen (And Made)

The "Everything is 200" Syndrome

Don't do this. If something failed, don't return 200 with an error message in the body. Your HTTP client libraries are built to handle different status codes – use them!

Ignoring Response Bodies for Errors

A 400 status code without explanation is useless. Always include helpful error messages.

Mixing Authentication and Authorization

401 for authentication failures, 403 for authorization failures. Keep them separate in your head and your code.

Not Monitoring Status Codes

Set up alerts for unusual patterns in your status codes. A sudden spike in 5xx errors might indicate a problem before users start complaining.

Testing Your Status Codes

// Best example for API testing
describe('User API', () => {
  test('should return 201 when creating user', async () => {
    const response = await request(app)
      .post('/api/users')
      .send({ email: 'test@example.com', name: 'Test User' });

    expect(response.status).toBe(201);
    expect(response.body).toHaveProperty('id');
  });

  test('should return 422 for invalid email', async () => {
    const response = await request(app)
      .post('/api/users')
      .send({ email: 'invalid-email', name: 'Test User' });

    expect(response.status).toBe(422);
    expect(response.body.details).toHaveProperty('email');
  });
});

Wrapping Up

Status codes aren't just numbers – they're a communication protocol between your server and clients. Getting them right makes debugging easier, improves user experience, and makes your APIs more predictable.

The next time you're building an API endpoint, take a moment to think: "What's the most appropriate status code for this scenario?" Your future self (and your teammates) will thank you.

What's your most encountered status code? Mine's probably 422 – I'm apparently really good at sending semantically incorrect requests to my own APIs! 😅

Drop a comment below with your status code war stories. We've all been there, and sharing these experiences helps us all become better developers.

Useful Resources:

HTTP Status Codes Registry - The official source
HTTP Status Dogs - Because learning should be fun
MDN HTTP Status Codes - Comprehensive documentation

From Web to Mobile: Completing My React Native Journey with Maximilian Schwarzmüller

Sidharth Sangelia — Sat, 30 Aug 2025 12:04:59 +0000

After weeks of dedication and hands-on coding, I’ve successfully completed Maximilian Schwarzmüller’s comprehensive React Native course on Udemy. As someone with a solid background in web development, this transition to mobile app development has been both challenging and incredibly rewarding.

A Little Backstory

I’ve always wanted to learn app development. Back in Class 12, I ambitiously tried setting up Android Studio, running the simulator, and building a simple app. What followed was an entire month of battling with environment variables, Java configurations, and errors I barely understood.

By the end of that month, I honestly questioned whether Android development was really for me. The complexity of the setup alone felt like a huge barrier to entry.

Looking back now, I can say this: React Native is a fantastic entry point into the mobile ecosystem. It lowers the barrier, lets you leverage existing React skills, and still leaves room to grow into full native development later as the need arises.

The Course Experience

Maximilian’s teaching approach struck the perfect balance between practical implementation and conceptual understanding. Rather than overwhelming students with theory, he focused on building real applications while explaining the “why” behind each decision. This hands-on methodology made complex mobile development concepts much more digestible.

Key Learning Milestones

Understanding the Component Ecosystem

One of the first major shifts was adapting to React Native’s component structure. Gone are the familiar HTML elements like div, p, and a. Instead, I learned to work with React Native’s specific components:

View instead of div
Text for all text content
TouchableOpacity for interactive elements
Image for media display

This wasn’t just a syntax change — it represented a fundamental shift in how mobile interfaces are constructed.

Navigation Patterns

Web development relies heavily on URLs and browser history, but mobile apps follow different patterns. The course covered:

Stack Navigator: For hierarchical navigation where users drill down into content
Tab Navigator: For parallel sections of an app
Drawer Navigator: For side menu functionality

Each navigation pattern serves specific user experience goals that don’t directly translate from web development.

Native Device Integration

Perhaps the most exciting aspect of React Native is its ability to access native device features. The course introduced me to:

Camera functionality
Location services
Device storage
Push notifications (overview)

Even in their simplest form, these integrations showed me the true power of mobile development — creating apps that live closer to users’ daily lives.

Reinforced React.js Skills

An unexpected benefit was how React Native deepened my React.js knowledge. Concepts like:

Component lifecycle management
State management patterns
Props and data flow
Hooks usage

… all became clearer when applied in a mobile context. It felt like practicing the same music scales on a different instrument — the repetition in a new setting gave me fresh perspective.

Challenges and Realizations

The Learning Curve

While my React background helped, mobile development brought unique challenges:

Understanding platform-specific behaviors (iOS vs Android)
Handling different screen sizes and orientations
Adapting to mobile-first interaction patterns
Debugging on physical devices vs simulators

Beyond the Basics

The course laid a strong foundation, but I know this is just the start. Areas I plan to explore further include:

Native module configuration
Advanced state management in mobile contexts
Performance optimization for mobile devices

Looking Ahead

This course gave me the confidence to start building mobile apps, while also showing me how much more there is to learn.

Immediate Next Steps:

Deep dive into push notifications
Exploring advanced native modules
Building more complex apps independently
Understanding app deployment and store submissions

Long-term Goals:

Mastering mobile-specific UX patterns
Platform-specific optimizations
Cross-platform best practices
Mobile analytics and performance monitoring

Advice for Fellow Web Developers

If you’re considering moving from web to mobile development:

Embrace the differences — don’t force web patterns into mobile contexts
Start with the fundamentals — get comfortable with React Native’s components
Test on real devices — simulators are great, but real-world usage is different
Be patient with native features — setup and testing can be tricky, but rewarding

Final Thoughts

Completing this React Native course feels like opening a door into an entirely new dimension of development. Web will always be my foundation, but mobile offers unique opportunities to create apps that integrate seamlessly into people’s daily routines.

The journey from web to mobile isn’t just about syntax or frameworks — it’s about understanding how people interact with technology in a more personal way.

Huge thanks to Maximilian Schwarzmüller for putting together such a structured and practical course. For anyone on the fence about learning React Native, his teaching makes the transition much less intimidating.

This is just the beginning of my mobile dev journey — and I can’t wait to see where it leads. 🚀 I will be sharing more of my learnings on notebook.thesidharth.com soon.

What about you? Have you ever tried transitioning between development platforms? Share your story — I’d love to hear it.

Building My First AI-Powered App: From Whisper to Vercel Limits

Sidharth Sangelia — Thu, 28 Aug 2025 19:17:50 +0000

I thought building AI apps would be about training models and complex machine learning stuff, but as I dug deeper, I found out - why reinvent the wheel when you can solve 70-80% of tasks with existing models?

Turns out, the real challenge wasn't the AI part. It was everything else.

The Idea: What I Wanted to Build

I'd been consuming tons of great video content on YouTube (both long and short form) and Instagram, and kept thinking: "This would make such a good blog post for better readability and SEO reach."

So I came up with what seemed like a simple solution - a NextJS 15 web app where users could:

Upload a video
Get AI-generated transcript using OpenAI's Whisper-1
Transform it into SEO-optimized content using ChatGPT/Gemini
Download a ready-to-publish blog post

How hard could it be, right? OpenAI already has Whisper for transcription, other LLM models are readily available through APIs. Just connect the dots and boom - instant article creation.

Plus, the blogging and content creation industry is booming. I thought if I could build this, maybe I could create some recurring revenue like the folks on Twitter always talk about.

🛠️ The Tech Stack (What I Thought I Needed)

Frontend & Backend: Next.js seemed like the obvious choice - I could handle both frontend and backend with API routes and server actions.

AI Processing: OpenAI's Whisper-1 for transcription, GPT-4/Gemini for content optimization.

Hosting: Vercel, because... well, it's the easiest deployment ever.

File handling: This became a whole saga (more on this below).

Here's what I thought the flow would look like:


// What I thought the flow would look like
const processVideo = async (file) => {
  const transcription = await openai.audio.transcriptions.create({
    file: file,
    model: "whisper-1"
  });

  const blogPost = await openai.chat.completions.create({
    model: "gpt-4",
    messages: [{
      role: "user",
      content: `Turn this into an SEO blog: ${transcription.text}`
    }]
  });

  return blogPost;  
};

Spoiler alert: It wasn't that easy.

⚡ First Reality Check: The 25MB File Upload Nightmare

My initial plan was to use UploadThing (Theo's creation) since it had a generous free tier. But then I discovered Whisper-1 has a 25MB file limit per upload.

Problem: Most decent-quality videos are way larger than 25MB.

In development, I could easily test with small videos under 25MB, but for a production app that people would actually pay for? This was a major roadblock.

Solution attempt #1: Extract audio from video (audio files are much smaller than video files).

I found ImageKit.io, which could handle uploads, compression, and audio extraction. Perfect! I ditched UploadThing and dove into ImageKit's documentation.

Spent hours implementing the audio extraction feature, writing code, testing locally. Everything looked good. Then came the moment of truth - testing the actual audio file extraction.

Nothing worked.

I added console.logs everywhere, thinking it was a code issue. After hours of debugging, I realized the problem: I'd exhausted ImageKit's free plan just from testing.

The kicker: ImageKit's paid plan costs $80/month and provides way less processing power than I'd need for a robust app.

Solution attempt #2: Use FFmpeg on my own server.

New problem: I'm a student without money for servers.

So I decided to postpone the audio extraction feature and just put a strict 25MB limit for now. "I'll figure this out later," I told myself.

💻 The API Integration That Worked... Until It Didn't

I implemented all the API integrations and functions. Everything worked beautifully on localhost. The transcription was accurate, the content optimization was decent, and I was feeling pretty good about myself.

Time to deploy and show my friends!

I deployed to Vercel, shared the link with excitement, and... nothing worked.

The app would start processing, show a loading state, and then just timeout with a 504 error.

After a lot of head-scratching and debugging, I found the culprit: Vercel's function timeout limits.

My processing pipeline was taking 60+ seconds:

File upload: ~10 seconds
Audio processing: ~20 seconds
Whisper transcription: ~30 seconds
GPT optimization: ~15 seconds

Google search time: "vercel function timeout limit"

The harsh reality:

Hobby plan: 10 seconds
Pro plan: 60 seconds
Enterprise: 15 minutes

Quick math: My processing takes 60+ seconds. Even the Pro plan wouldn't save me.

Bigger realization: This isn't just a Vercel problem. AWS Lambda has 15-minute limits, Netlify has similar constraints. Serverless functions aren't meant for long-running tasks.

❌ What I Built:  User Upload → Vercel 
   Function → Process (60s) → Timeout.

✅ What I Actually Needed:  User Upload → Queue 
   Job → Background Worker → Notify User

🤔 Understanding the Real Problem

Here's what I learned about serverless architecture the hard way:

Serverless functions are great for:

Fast responses (under 30 seconds)
Auto-scaling
Quick API endpoints
Simple data processing

Serverless functions are terrible for:

Long-running AI processing
File manipulation tasks
Complex workflows
Anything that takes time

The fundamental issue: I was trying to fit a long-running AI workflow into a request-response architecture. That's like trying to fit a truck through a car door.

🔧 Solution Discovery: Enter Background Jobs

Back to Google: "background jobs nodejs", "async processing for AI apps"

I discovered several options:

Inngest - Developer-friendly, good free tier
BullMQ - Redis-based, more complex setup
AWS SQS - Powerful but overkill for my needs
Redis Queue - DIY approach

I chose Inngest because:

It handles the infrastructure for me
Great developer experience
Built-in retries and error handling
Free tier was sufficient for testing

Here's the new architecture:

import { inngest } from "./inngest/client";

// API endpoint just queues the job (fast!)
app.post('/api/process-video', async (req, res) => {
  const jobId = await inngest.send({
    name: "video/process",
    data: {
      videoUrl: req.body.videoUrl,
      userId: req.body.userId
    }
  });

  res.json({
    message: "Processing started! We'll notify you when it's ready.",
    jobId,
    checkStatusAt: `/api/status/${jobId}`
  });
});

// Actual processing happens in background (no time limits!)
export const processVideo = inngest.createFunction(
  { id: "process-video" },
  { event: "video/process" },
  async ({ event }) => {
    // Now I can take all the time I need
    const transcription = await processWithWhisper(event.data.videoUrl);
    const blog = await optimizeWithGPT(transcription);

    // Notify user when done
    await notifyUser(event.data.userId, blog);
  }
);

The difference: Instead of making users wait for 60+ seconds (and timing out), I immediately return a "we're processing it" response and handle the heavy lifting in the background.

📚 What I Actually Learned

Architecture Matters More Than I Thought

You can't just throw AI processing into a standard web app architecture and expect it to work. AI apps have fundamentally different requirements:

Long processing times
Unpredictable resource usage
Need for progress tracking
Error handling for expensive operations

Research Infrastructure Constraints First

I should have researched deployment limitations before writing a single line of code. Now I know to ask:

What are the timeout limits?
How much memory/CPU can I use?
What happens if processing fails halfway through?
How do I handle user notifications?

The Hardest Part Isn't the AI

I thought the challenging parts would be:

Getting good transcriptions
Optimizing content for SEO
Fine-tuning prompts

Actually challenging parts:

File upload and processing
Background job orchestration
User experience for async operations
Error handling and retries
Infrastructure costs and scaling

Local Development Can Be Misleading

Everything worked perfectly on my MacBook Pro. But production environments have:

Stricter resource limits
Network latency
Timeout constraints
Different error conditions

Lesson: Test in production-like environments early and often.

🔮 What I'm Building Next

I'm currently rebuilding the entire app with background jobs as a first-class citizen:

New tech stack:

Frontend: Still Next.js, but with real-time progress indicators
Background jobs: Inngest for orchestration
Database: Adding Supabase for job status tracking
File storage: Moving to Cloudinary for better video handling
Notifications: WebSocket connections for real-time updates

Timeline reality check: What I thought would be a 2-week project is now a 3-month learning journey. And honestly? I'm more excited about it now.

Other technologies I discovered:

Langchain & Langraph: For more complex AI workflows
Redis: For caching and session management
WebSocket/Server-sent events: For real-time progress updates
Queue monitoring tools: For debugging background jobs

💭 Advice for Other Developers

If you're building AI-powered apps, here's what I wish someone had told me:

Plan for Async from Day One

Don't build a synchronous AI app and try to make it async later. Design your user experience around the fact that AI processing takes time:

Show progress indicators
Send email/push notifications when jobs complete
Let users check status later
Handle failures gracefully

Research Your Platform's Limits

Before you write any code, understand:

Function timeout limits
Memory constraints
File size restrictions
Pricing for overages

Start with Background Jobs

Even if your AI processing is currently fast, it will get slower as you add features. Background jobs give you:

Better user experience
Easier scaling
Retry mechanisms
Progress tracking

Infrastructure Is Harder Than AI

Getting good results from OpenAI's APIs is pretty straightforward. Getting those results reliably delivered to users in production? That's the real challenge.

It's Totally Normal

If you're struggling with infrastructure for AI apps, you're not alone. Every AI developer goes through this learning curve. The AI part is often the easy part.

What about you?

Have you hit similar serverless limitations while building AI apps? What solutions did you find?

Are you currently building something with AI? What infrastructure challenges are you facing?

Drop a comment below - I'd love to hear about your experiences and maybe we can help each other avoid these pitfalls!

Currently rebuilding this app the right way. Follow my journey as I document everything I learn about building production-ready AI applications.