How I Built a Serverless Community Platform in 72 Hours Using Kiro (Without Being a Developer)
I´m a TAM with no dev background that used Kiro to build a complete community platform with S3, CloudFront, Cognito, Lambda, and API Gateway all using vibe coding. Here's the architecture, the problems, and what broke in production.
It Started with an Idea
The community already existed, but everything was manual.
I wanted a central place where Brazilian Golden Jacket holders could connect, share content, and collaborate.
My initial requirements were simple:
- Dark theme
- Gold visual identity
- Member cards with photos
- A map showing where members are located
- Responsive design
Nothing revolutionary.
I opened Kiro and started describing what I wanted.
Instead of spending hours searching documentation or learning frontend frameworks, I simply kept refining the requirements through conversation.
A few hours later, I had a functional website deployed on Amazon S3 behind CloudFront with a custom domain and SSL certificate.
It wasn't perfect, but it was live.
At that moment there were only two members online, but seeing a real website running from an idea I had that same day felt pretty incredible.
Then Things Escalated
Once the public website was working, I wanted something more useful:
A private Members Lounge.
Only verified members should be able to access it.
Kiro helped implement authentication using Amazon Cognito.
The flow included:
- User registration
- Temporary passwords
- Password reset
- Forced password change at first login
- Session management
By the end of the first day, the platform was already doing much more than I originally planned.
I finally stopped working sometime after 2 a.m.
The Workflow That Changed Everything
The most interesting part wasn't authentication.
It was automation.
I wanted new member applications to be reviewed before appearing publicly on the site.
The final workflow became surprisingly elegant.
When someone submits an application:
- API Gateway receives the request.
- A Lambda function processes the data.
- The member photo is uploaded.
- A GitHub branch is created automatically.
- The member card is generated.
- A Pull Request is opened for review.
I simply review the PR and click Merge.
GitHub Actions takes care of the deployment, synchronizes files to S3, and invalidates CloudFront.
From application submission to publication, the entire process usually takes less than a minute.
The exact same model was later reused for article submissions inside the Members Lounge.
Members can contribute content without touching the source code, while I still keep a review process in place.
Production Bugs Are Still Production Bugs
AI can generate code.
It cannot eliminate reality.
One of the first issues appeared when a member named João submitted an application.
The workflow failed unexpectedly.
After some investigation, we discovered that the Lambda function was using the member name in the Git branch creation process.
Git branch names and special characters don't always get along.
The fix itself was simple:
- Normalize names for branch creation
- Preserve original accents on the website
The whole issue took only a few minutes to solve.
Another bug was far more frustrating.
The application button suddenly stopped working.
No obvious error.
No warning message.
Nothing.
Users clicked the button and absolutely nothing happened.
After around twenty minutes of confusion, Kiro helped isolate each JavaScript block and identify a single misplaced brace.
One extra
} was enough to break the workflow.That experience reminded me that debugging remains debugging, regardless of how the code was created.
The Architecture
The architecture is intentionally simple:
- Amazon S3 for static hosting
- Amazon CloudFront for content delivery
- AWS WAF for basic protection
- Amazon Cognito for authentication
- Amazon API Gateway for APIs
- AWS Lambda for backend processing
- Amazon SNS for notifications
- Amazon DynamoDB for visitor statistics
- GitHub Actions for CI/CD
Nothing exotic.
These are services many AWS practitioners use every day.
The difference wasn't the technology.
The difference was the speed at which it came together.
What I Learned
At AWS re:Invent 2025, Werner Vogels talked about the idea of the "Renaissance Developer."
The concept resonated with me because it shifts the focus away from writing every line of code manually and toward understanding systems, architecture, and business problems.
Building this platform made that concept feel very real.
The biggest bottleneck wasn't coding.
It was having clear requirements and making good architectural decisions.
The AI helped with implementation, but I still had to think about security, authentication, workflows, deployment strategies, and operational impact.
Three days later, the platform was running in production.
Today it supports dozens of Golden Jacket members across multiple Brazilian states, provides a private collaboration space, automates onboarding, and continues to evolve.
Perhaps the most surprising part is that the entire journey started with a conversation.
And, in many ways, it still runs on conversations.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article