What Building and Deploying a Real Production App Taught Me Beyond Tutorials

Panic Engineer — Mon, 18 May 2026 09:39:53 +0000

Recently I finished building and deploying a production real-estate platform for a non-technical client using:

Next.js
MongoDB
Cloudinary
Vercel

The project itself wasn’t “massive” from an enterprise perspective, but it taught me something important:

real-world software engineering starts where tutorials usually stop.

A lot of my learning during this project had very little to do with writing React components or building CRUD APIs.

Instead, most of the valuable lessons came from:

debugging production issues
handling infrastructure constraints
deployment behavior
SEO/discoverability
UX/business tradeoffs
understanding how technical decisions affect real users

The Difference Between “Building Features” and “Shipping Products”

Before this project, most of my learning came from:

tutorials
isolated side projects
local development environments

In those environments:

APIs usually work
deployment is ignored
infra is abstracted away
assets are small
performance doesn’t matter much
search engines don’t exist
users don’t exist

Production projects behave very differently.

Once real users, real hosting platforms and real business requirements enter the picture, software engineering becomes much more holistic.

Vercel Payload Limits and Large Image Uploads

One of the first interesting issues I encountered happened during property creation.

The admin could upload multiple high-quality property images. Initially everything worked fine with smaller images, but once I started testing realistic production scenarios with larger files, uploads suddenly started failing.

At first I suspected:

Cloudinary upload issues
MongoDB problems
request handling bugs

None of those were actually the problem.

The real issue was that the total request payload exceeded Vercel’s limits before the upload logic even completed.

This was one of those moments where I realized:
production platforms have infrastructure constraints you rarely encounter in tutorials.

The Fix

Instead of blindly increasing limits or changing infrastructure immediately, I implemented client-side image optimization/compression before submission.

The result:

drastically reduced payload size
significantly improved reliability
better upload performance
reduced bandwidth usage

This was also a reminder that optimization is often about understanding constraints rather than prematurely overengineering systems.

Cloudinary PDF Preview Behavior

Another interesting issue involved property PDFs.

The client wanted uploaded PDFs to preview directly in browser rather than forcing users/admins to download them.

Initially, Cloudinary-hosted PDFs were downloading instead of previewing.

I tried:

URL manipulation approaches
response behavior tweaks
different delivery methods

Eventually I discovered that using Google Docs Viewer as a lightweight preview layer solved the issue cleanly.

The implementation itself wasn’t complicated, but the interesting part was the debugging process:
understanding browser behavior, file delivery behavior and how external services interact together.

Deployment Is a Different Skillset Entirely

Before this project I underestimated how much engineering exists beyond writing application code.

Deployment introduced an entirely different category of problems:

DNS propagation
custom domain setup
SSL behavior
Vercel deployment restrictions
GitHub contributor behavior
infrastructure caching

One interesting moment happened during custom domain setup.

Some devices/networks showed the updated Vercel deployment immediately, while others still displayed the default GoDaddy placeholder page.

Initially it looked like a broken deployment.

The actual issue:
DNS propagation and ISP-level caching differences.

This taught me that deployment debugging often involves understanding distributed systems behavior more than application logic itself.

SEO Is More Technical Than I Expected

This was also the first time I handled SEO/discoverability setup seriously for a production project.

That included:

sitemap.xml
robots.txt
OpenGraph metadata
canonical URLs
Google Search Console
indexing requests

One thing I realized quickly:
deploying a website does not mean search engines automatically understand or discover it properly.

There’s an entire layer of infrastructure and communication happening between:

your application
crawlers
social platforms
indexing systems

Even after submitting the sitemap and requesting indexing, Google still needed time to crawl and process the website.

At first many pages simply showed:
“URL is unknown to Google.”

That experience helped me understand that SEO is less about “gaming rankings” and more about:
clarity, discoverability and technical communication.

Lighthouse Scores vs Real UX

Another useful lesson came from performance optimization.

I tested the project using Lighthouse/PageSpeed and the scores were actually quite good overall.

But I also realized something important:
blindly chasing perfect benchmark scores can become counterproductive.

For example:
real-estate platforms naturally depend heavily on high-quality imagery because trust and presentation matter.

Aggressively compressing everything or removing visual quality purely to maximize Lighthouse scores can negatively affect actual user perception.

That changed how I think about optimization.

Good engineering is often about balancing tradeoffs:

performance
aesthetics
usability
responsiveness
business requirements

rather than maximizing a single metric at all costs.

Mobile-First Thinking Changed A Lot

This project also changed how I think about mobile UX.

Real-estate traffic is heavily mobile-first.

While testing the production deployment on actual devices, I realized that many interfaces that felt “clean” on desktop became frustrating on smaller screens.

That affected decisions around:

spacing
modal behavior
tap targets
navigation
lead capture flow
scrolling experience

Responsive design is not only about making layouts fit smaller screens.
It’s about reducing friction during real interactions.

AI Tools Accelerated Development, But Didn’t Replace Engineering

AI tools definitely accelerated parts of development during this project.

They were extremely useful for:

speeding up implementation
generating boilerplate
exploring approaches
debugging directionally

But the hardest parts still required engineering judgment:

identifying root causes
understanding constraints
evaluating tradeoffs
adapting architecture
debugging infrastructure issues
balancing UX and business goals

The “generate code” layer was only one part of shipping the product.

Technical Decisions Directly Affect Business Outcomes

One of the biggest mindset shifts during this project was realizing how directly technical decisions influence business outcomes.

For example:

improving upload reliability improved admin experience
better metadata improved social previews
SEO setup improved discoverability
mobile UX decisions reduced friction
lead capture flow decisions affected conversions

The project gradually stopped feeling like:
“building features”

and started feeling more like:
“designing systems that solve business problems reliably.”

Why This Project Was Valuable

The most valuable part of this project wasn’t the final deployment itself.

It was learning that real-world engineering involves much more than writing code:

debugging unfamiliar problems
understanding infrastructure behavior
communicating with non-technical stakeholders
balancing tradeoffs
improving reliability
thinking about users/business impact
shipping systems end-to-end

I think that’s why production projects teach differently from tutorials.

They force you to move beyond:
“Does this work locally?”

and start thinking:

What happens in production?
What happens under constraints?
What happens for real users?
What happens after deployment?
What breaks unexpectedly?
How do we recover/debug systematically?

Still learning, but this project definitely changed how I think about software engineering.

Building SOC-AI: Sub-Second Security Triage with Groq & Kestra

Panic Engineer — Tue, 06 Jan 2026 12:38:00 +0000

The Motivation: Solving Alert Fatigue 🛡️

Security teams are drowning in logs. I built SOC-AI solo during the AI Agents Assemble Hackathon (hosted on @wemakedevs) to prove that AI can handle the "boring" triage while humans keep control.

The Architecture

Triage: Groq (Llama-3.3) for 500ms log analysis.
Orchestration: Kestra for semi-autonomous remediation.
Frontend: Next.js 15 (Live on Vercel!).

Technical Deep Dive – Reliable AI & Orchestration

One of the biggest challenges in AI agents is hallucination. In a security context, a "hallucinated" IP address or action could be a disaster. I solved this using two core patterns:

1. Forcing Structured Output with Zod & Groq

I didn't just ask the AI to "analyze the log." I defined a strict contract using Zod. This ensures that the high-speed Llama-3.3 model on Groq returns a precise JSON object that my backend can trust.

// Define the Triage Schema
const SecurityTriageSchema = z.object({
  severity: z.enum(["low", "medium", "high", "critical"]),
  threat_type: z.string().describe("Categorization like Brute Force, SQLi, etc."),
  action_suggested: z.enum(["block_ip", "disable_user", "monitor"]),
  reasoning: z.string()
});

// Forcing Groq to adhere to the schema
const chatCompletion = await groq.chat.completions.create({
  model: "llama-3.3-70b-versatile",
  response_format: { type: "json_object" }, // Crucial for reliable JSON
  messages: [
    { role: "system", content: "You are a SOC Triage Agent. Output ONLY JSON." },
    { role: "user", content: `Analyze this log: ${rawLogData}` }
  ],
});

2. Semi-Autonomous Remediation via Kestra

Trust is everything in security. Instead of letting the AI run wild, I built a Human-in-the-Loop system.

When the AI suggests an action (like block_ip), it appears on my Next.js Dashboard. Only after I click "Approve" does the backend trigger a Kestra Workflow.

Why Kestra?

Retries: If the Firewall API is down, Kestra handles the retry logic.
Audit Trail: Every action taken is logged visually in the Kestra UI.
Separation of Concerns: My Next.js app handles the UI, while Kestra handles the heavy infrastructure automation.

The Result

By combining Groq's speed with Kestra's reliability, SOC-AI can triage a log and present a remediation plan to an analyst in less than a second.

This project was a solo build, and it taught me that the future of AI isn't just about the "chat" - it's about orchestration.

Links & Demo

GitHub: https://github.com/kaushik0010/soc-ai
Video Walkthrough: https://youtu.be/LbuHXiPznJE

What are your thoughts on semi-autonomous security? Would you trust an AI to suggest your firewall rules? Let's talk in the comments!

DEV Community: Panic Engineer