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.