Forem: Will Cheung

I Built and Deployed a Micro-SaaS in 3 Hours — Here’s What I Learned

Will Cheung — Sun, 31 Aug 2025 20:33:55 +0000

I’m not a software engineer, but I’m a relatively technical tinker. In earlier posts, I built apps using Replit, Firebase Studio, and Gemini Canvas. Gemini Canvas is pure magic for spinning up an idea in 30 seconds with zero code, but it doesn’t do well for more complex apps that need a database. Firebase Studio is great if you want a powerful, scalable setup — but it can feel a bit unwieldy for a hobbyist like me (I’ll do a deeper dive on that later).

That’s where Replit shines. It’s a sort of Swiss Army knife — a perfect middle ground for quickly going from idea to deployed app. In this article, I’ll go deeper into the pros and cons of going production-ready on Replit.

Note #1: This isn’t a step-by-step guide. Other articles do that much better — this is more about my experience using Replit to ship something real.

Note#2: I’m using the paid version of Replit, which gives me a better model with better prompt reasoning and code generation.

Why going to production requires more than just code

If you’re new to all this, here are a few basics that separate a toy app from one that’s production-ready:

✅ Database — Storing user data and app data.
✅ Custom domain — Giving your app a real branded URL.
✅ Hosting — Moving from “local preview” to “actually live on the internet.”
✅ Deployment — Transitioning from sandbox to a real, stable environment.
✅ Monitoring — Checking errors and usage after going live.

This typically requires 5+ tools. And the cool thing about Replit? It takes care of all of this out of the box.

People often talk about no-code tools making it easy to ship SaaS apps without writing a single line of code — that’s mostly true. Going to production, for example, is another story.

Even though Replit Agent wrote most of the code, I still had to code review and occasionally debug. But the speed production code is generated is mind-blowing. That’s what allowed me to build something meaningful in hours instead of days or weeks.

What I built

Let me introduce Calendar Autobot, your AI assistant to transform any emails and images into calendar events. You can literally forward an email with a flight itinerary or kids camp schedule, and the bot will add the event to your Google Calendar. A few caveats:

I might add a SMS feature, making it easier to send images
Adding email support was extra work that took me beyond the 3-hour goal.
Vibe coded Chrome Extension as well

Impressive debugging saves the day

Every app has bugs — yes, especially the ones built by AI. And debugging isn’t just about fixing the problem; it’s about playing detective: reading logs, tracing the code path, and narrowing in on what went wrong. Sometimes a typo can take (a human) hours to find!

What surprised me is how well Replit handled all that on its own. Without me having to point it in the right direction, it flagged issues I hadn’t even noticed — just by parsing the logs.

Pro tip: I had Replit add a bunch of logging early on, which turned out to be a huge help for its AI when it came time to debug. Highly recommend that.

What’s the catch?

There were several places where the Replit Agent/Assistant got stuck. Replit always gives a preview of the code it is about to write, and sometimes the logic doesn’t make sense. When they’re stuck they do one of the two things:

❌ The AI sometimes bloats the codebase — creating new code instead of fixing existing logic.
❌ It can also spin in circles, especially around tricky third-party integrations like Google OAuth or Mailgun.

When that happened, I had to jump in — pasting documentation links and writing hyper-specific prompts to steer the AI in the right direction. Even so, that’s faster than writing everything myself. What took me a few hours could easily have taken me 3–4 weeks solo.

Other considerations that slows down development

💡 What happens when users don’t give OAuth consent?
💡 What if users forward random spam emails?
💡 What happens when there are many events in a single email? (note: this is purely prompt engineering, not coding)

The details

Tech stack:
Python, Flask, PostgreSQL
Integrations: OpenAI, Google OAuth, Mailgun

Where Replit saved the most time:
✅ Bootstrapping: A single prompt gave me an app 70% of the way. I used Google AI Studio to generate the prompt, so even prompting was made simple!

Here’s my starter prompt:

Using Python Flask and Google AI Python SDK, create a backend API service that transforms text into calendar events. It takes some text, either from email or document, and extracts date information from them. Text can be a travel itinerary, school event, or any date/time related events. From the extracted data, integrate with Google calendar and create corresponding events. For frontend, use any popular framework.
A sample prompt I would feed into this API would be:
Given the following text, extract all event information. For each event, identify:
The event name.
The event description that gives context to this calendar event.
The start date (in YYYY-MM-DD format).
The start time (in HH:MM 24-hour format, if specified).
The end date (in YYYY-MM-DD format, if specified or different from start date).
The end time (in HH:MM 24-hour format, if specified).
The location (if specified).
If a date is relative (e.g., “next Monday,” “tomorrow”), assume the current date is [INSERT CURRENT DATE HERE, e.g., 2023–10–27] for resolving it.
Provide the output as a JSON list, where each object in the list represents an event with keys: “event_description”, “start_date”, “start_time”, “end_date”, “end_time”, “location”. If a piece of information is not found, use null or an empty string for its value.
Text: “”” [PASTE THE EMAIL/DOCUMENT TEXT HERE] “””

✅ Refactoring code: At one point, routes.py got too big to manage, so I have to get it to rewrite it.

✅ Marketing and Branding: Replit generated a logo and marketing page for me. I don’t even have to write marketing copy!
✅ DB Migration: Replit automatically creates mini scripts to run for database migrations

✅ Deployment to production: Going live was literally one click. This alone would have taken me a week to figure out.
✅ Error fixing: Fixing errors that pop up every now and then. Simply prompt: fix error in console and it just does it. This is slightly different than debugging, which is still somewhat manual and takes up most of my time (more details below).
✅ Collaboration: While I didn’t use this feature, it’s touted as one of the differentiators compared to other vibe coding tools
✅ Source control: Versioning and simple source control built-in

Where I spent the most time wrestling Replit

🔍 Google OAuth: It initially generated working code, even though very messy, inefficient auth workflow. I had to correct this by prompting specific fixes, but it just resulted in more bloated code and unnecessary API calls. Eventually, I pasted the official docs and prompting the AI carefully, and it worked as expected.

Pro tip: I’m surprised how great Replit’s AI is at reading external documentation. If you’re technical and know that AI is generating garbage code, just feed it dev docs like this one.

🪲 Debugging: If something went wrong and Replit couldn’t figure it out after several tries, I was back in the driver’s seat — manually reading logs and helping the AI understand what to do.
Pro tip: Disable “automatically publish changes” and review Replit’s code, especially for big changes. It will save a lot of time later on if something doesn’t go as planned because you’re in the loop.

⚠️ Production control: One-click deployment is great, but if something breaks, logging is limited (oftentimes crashes) and prod database setup is non-existant.

Pro tip: Always use a separate production database, and I’m seriously considering using external logging analytics.

The verdict

Is Replit perfect? No.
Is it amazing for hobbyists? Absolutely.

If you value speed, ease of use, and getting something real into the world over fine-tuning every deployment detail, Replit is one of the most productive tools you’ll ever use. It’s a terrific all-in-one platform for side projects or small SaaS apps where moving fast is more important than absolute control.

And that’s exactly why I’ll keep using it — especially when my goal is shipping something fun without overthinking it.

Follow me on X (https://x.com/willcheung) for more insights like this.

Launched & Lessons Learned: SMS order-ahead platform with Twilio & Square API

Will Cheung — Sun, 11 Oct 2020 16:31:22 +0000

In my first post, I wrote about my ambitious project to create a SMS order-ahead platform & CRM for small business. The goal was to help coffee shops & restaurant owners to digitally accept new orders (like a Starbucks app) without the 30% commission charged by on-demand delivery businesses. Not to mention, I believe that digital (specifically text/chat) is the future of customer communication. So, I'm happy to announce that I've launched the text-ordering bot, Textbot!

Why I built a to-do list first, and how it evolved

The reason why I chose to create a to-do list is to find the most-common-denominator feature that could power potential sms bot ideas. SMS ordering-bot was just one of my initial ideas. I also had thought about SMS queue-management system for restaurants and simply to keep a list of inventory via text messages, without the bulky app installation & registration. In addition, I even thought about exposing the SMS queue-management platform API, so anyone can use it to build whatever list they want.

The idea quickly turned into a full-blown ordering and payment system when I started talking to food trucks and independent coffee shops about their pain points. Not only do they want to offer digital ordering to their customers, they don't want to be charged 30% by DoorDash or invest time to setup a new order-ahead app. The biggest revelation was probably the time that these businesses took to invest in creating their menus in these new order-ahead apps.

Pain points of these SMBs:

30% commission fee is outrageous, but necessary to survive. Margin is razor thin.
Willing to pay a little money to offer existing customers a way to order-ahead. Some opt for traditional call-in-to-order. Others invest in 3rd party apps/websites.
For those who invest in 3rd party apps, creating a menu is the biggest pain points. They have to take professional pictures, post it with a description, create categories/add-ons, and then publish the menu.
Menu management is also difficult with these apps, especially for sold-out items.

Which means our MVP needs to:

Be frictionless for consumers to order from these businesses. This means no app installation, no registration, and can start ordering right away.
Be frictionless for store owners to get started & setup their menus
Offer online payment

Discovering the most important player in the ecosystem

As I paid more attention to how restaurants and coffee shops take orders and allows digital orders, I started to notice a POS (point of sale) system that most "modern" businesses use - Square. (The reason why I put quotes around "modern" is because most businesses are cash-only or non-tech savvy. More on this later.) Since I want to offer online payment where these SMBs can use their existing POS to accept payment (and the store owners are more tech-savvy), then Square is a clear winner.

I actually didn't integrate with Square from the beginning. Instead, I used Stripe because I had previous experience with their API and they have a very robust marketplace product called Stripe Connect that is being used by Uber, DoorDash, etc. There were several offerings, one of which is white-label solution (like Uber, DoorDash, etc.), and the other method onboards customers via Stripe's own onboarding process. As a single person team, I didn't want to be liable of payment fraud or ordering errors, plus the ease of integration is much lighter, I chose to onboard store owners via Stripe and defer those responsibilities to the store owners themselves.

Integration was a breeze, and I mainly used Stripe integration as a live demo to store owners. Behind the scenes, I knew Square is the POS that I need to integrate with. As I started Square integration, I even participated in Square Hackathon! Their API and documentation isn't as rich as Stripe, but it wasn't hard to hack together a prototype to sign up a few beta customers.

Square + Twilio = Great Product

I worked with a few beta customers to streamline the ordering process. The product is beautiful, figuratively, since SMS actually has no UI. But the customer flow is exactly how I imagined the future to become.

Customer flow:

Customers text to order their coffee, food, farmer's market items, etc. Customers checkouts via our Square checkout integration. (You can try a live demo - text "order @textbot" to 215-8TEXTME)
We send the order directly into businesses' POS or Square account so vendors don't need to use another tool; we operate in the background. They can use our order management system if they don't have Square.
When the order is ready, tab "Done" inside Square POS. The webhook will send an event so we can text customers that the order is ready.

Store owner flow:

This is much more difficult, since there are multiple humps that store owners need to go through to get started. I'm familiar with this SaaS sales funnel, so I got started like the following.

Sign up using Square SSO, or sign up with email without Square.
Setup a business profile, much like an Instagram handle. I'm imagining a world where Textbot can order food from anywhere.
Setup menu, and we made it really easy. For example, no pictures are required for SMS.

Go to market experiments and concerns

Signing up customers was really, really difficult. Imagine a door-to-door salesman selling magazine subscriptions in the past - it's like that. But because we provide a poster for store vendors to tape on their window about how to order-ahead with Textbot, I thought we had a chance for word-of-mouth marketing.

So I identified a cluster of coffee shops, casual restaurants, and farmers market, and just went door to door. It was painful but enlightening:

Most customers are not tech-savvy. They asked a lot of basic questions about how order-ahead generally works. I used analogies like Starbucks app to order ahead coffee, but every sale takes a lot of time and many touch points.
SMS ordering is a pretty new concept, so this definitely adds to the "customer education" sales process
Some don't use Square.
Digital marketing conversion isn't great. It may be because I haven't fine-tuned the keywords, but it could also be because most store owners are not technical.
It is definitely not scalable, at least not something I can do part-time after work.
I started targeting farmers markets, where I can target a cluster of store owners. Most accept cash / Venmo and not many use Square.
In my last startup, I found a lot of success being a partner in marketplaces for Chrome extension. I applied to become a partner at Stripe and Square. Stripe doesn't drive much qualified traffic, as expected, and Square doesn't list Textbot as a partner until we hit 100 active customers.
This one is big: even when customers sign up, they still have to do their own marketing to encourage customers to order via SMS. We made it easy so store owners can print out a poster to tape on their entrance - to tell their customers how to order via text, and even added QR code. But most store owners see this as retaining existing customers, but not as getting new ones. In SaaS world: Sales > Customer Success

Final thoughts

Even though there's an explosion of order-ahead and digital payment for brick & mortar businesses, targeting them isn't very scalable. Without a scalable digital channel, I actually have to spend time in the field getting the first 100 customers, instead of just investing money in marketing. Moreover, I'm sure this was done years ago (perhaps via SMS or Facebook Messenger) and never took off. Was the market not ready? I wonder what were the learnings then?

However, the recent explosion of e-commerce might present an opportunity to bring Textbot to that market instead. It's a crowded, albeit big, market. Perhaps Textbot will become a look-alike, or it will be the next big chat-based CRM. We will see what happens.

What would you do?

Twilio Hackathon: Todo-list Textbot - User Flow with Studio Flow

Will Cheung — Sat, 18 Apr 2020 19:42:27 +0000

Hey there. Since my first post on Twilio Hackathon, I've made some good progress. In this post, I'm going to go over user flow design and how I used Studio Flow to stitch my to-do list textbot together.

User flow challenges

The biggest challenge of the textbot is having multiple trigger words to take users into different paths. After watching some Studio Flow tutorials, I embarked on the user journey. I started with a simple path to sign-up users. It quickly got complicated as I added more commands for the bot.

As an overview, these are the commands that I planned for this hackathon:

"hi" - sign up
"add item" - add an item to list. If list doesn't exist, create one.
"remove item" - remove item by name or number
"show items" - show all items in list

User Flow v1

To give you an idea how I thought through the process, here's a first version.

Each green box is one Studio Flow, and each Flow calls the corresponding API to manage the list. This design decouples the "bot" and the backend, so the Rails app is simply an API that handles requests and backend. Simple enough. I went to work and discovered a few challenges/learnings.

While technically, I can just create a single big Flow that covers all the conditions/branching, I chose a design where each Flow is decoupled and modularized. No monolithic design!
To connect the Flows, I wrongly assumed that a single phone number can associate to multiple Flows. I had thought that when a user texts the phone number, every Flow will evaluate the trigger words and go down the corresponding Flow when triggers match. Thinking back now, it makes total sense that one phone number can only trigger one Flow. Here's more details about this topic.
Learnings: I needed something that parses all the commands, and then trigger "sub-Flows".

User flow v2

Here, a Flow process commands, and triggers other nested Flows based on string condition. A Flow can be triggered via Studio Flow REST API and from another Flow, which helps.
Pros: Single point of entry for SMS.
Cons: I wasn't satisfied with the split-based-on widget. While string parsing with Regex is enough to parse most text, but building more than a "Yes"/"No" condition, it quickly gets complicated and becomes difficult to manage (like this example). A case statement is much easier to code and manage, especially when there are nested conditions.
Learnings: While everything kind of works, I found that it was difficult to overcome the lack of control, the unwieldiness of the Flows, and the limitation on debugging. I decided to bring the "command parsing" into code.

User flow v3

Blue box is the Rails app, green boxes are Flows. Here, I'm leveraging a Flow to listen to SMS to trigger and sign up. I could have combined both sign-up and trigger into my app, but the main reason they're in a Flow is because I love using Send & Wait Reply Widget, which will take some work to build manually.
Caveat: While using Send & Wait Reply Widget, if the Flow is triggered via Studio Flow REST API, the "wait" part doesn't respond to the user's text. Not sure if it's a bug or by design, but that's the main reason why this Flow is triggered by text in this design, not by my app.
Leveraging my app to process all the commands. This enables me to use all kinds of string manipulation and case statements, and allows me to use Studio Flow REST API to tigger corresponding Flow.

Conclusion - Think like Lego Master Builder

Studio Flow is awesome. It's great for anyone, technical or not, to quickly build a chatbot. With the rise of low/no-code development, it's definitely going to gain more traction. The big plus here is allowing non-coders to build a simple bot, without bothering developers to build it. :)

However, Flow isn't like software development. If your bot features will grow and evolve over time, I recommend writing software rather than building Flows. Since I started using Studio Flow, I've learned to think of Flows as drag & drop AWS Lambda functions. They're very good at building point solutions, and need to be broken down into smaller and more manageable pieces.

As an example, I've been looking for ways to programmatically check in the Flows in source control, creating dev/prod Flows, and "migrating" them into production mode. Twilio's Studio REST API v2 will be interesting and might help close some of these gaps. During your development process, consider trade-offs between building software and creating Flows that cater towards your use cases.

Twilio Hackathon: Shared (to-do, grocery) lists between friends, family, and businesses

Will Cheung — Sat, 11 Apr 2020 22:40:49 +0000

My first post on dev.to, and fist ever hackathon!

I'm a tinkerer and builder, and I went as far as founding + raising money for a startup via one project. Moreover, I believe the future of business communications is evolving from websites (2000s), to mobile apps (2010s), and to text/chat (2020s). This is my first time playing with Twilio API in depth and I'm excited to dig in.

What I'm going to build

I started out brainstorming an ambitious project of text/chat for local businesses to interact with consumers, so businesses don't have to invest in costly websites/mobile apps to go digital (think restaurants take-outs, coffee shops order-aheads). Especially in covid-19 world, local businesses are even more dependent on take-outs via phone, deliveries, and "non-physical" channels.

However, the project has been reduced in scope to a simple to-do or grocery list for this hackathon. This will serve as a platform for anything that requires a list, like menu items, order list, grocery list, etc.

MVP features:

Sign up
Add items
Remove items
Show items
Manage multiple lists
~~Share/collaborate list with friends/family (if time allows)~~
(Edit 4/29): Invite via vcard / MMS

Category Submission:

Exciting X-Factors

Demo Link

Text "hi" to 616.344.5566

Edit (4/13): Deployed to AWS EBS and "hi" in the cloud! Do note that EBS is a bit janky with Rails 6, so I wrestled with it a bit. Might go with a container next time.

Edit (4/18): All commands on screens below should work. Looking forward to some feedback!

Link to Code

Edit (4/20): Code includes Rails 6 app and Twilio Studio Flow exports. Setup instructions in README.

willcheung / textbot-rails

How I built it

My current stack:

Twilio SMS API
Twilio Studio Flow + API
Rails 6
Postgres 12

I had planned to use AWS Lambda instead of Rails, but struggled to get Ruby running on Lambda and talking to RDS. Having built my last startup in Rails, I'm able to get a Rails app running 100x faster than Lambda :). Also, I get flexibility to create a UI if needed.

Additional Resources/Info

Edit (4/14):
I ran into a few limitations (features?) with Studio Flow.

Studio Flow only allows one flow tied to one (to many) phone number(s). This means I cannot "modularize" and create multiple flows based on trigger keywords. For example, I'd like "Add" to trigger one flow, and "Remove" to trigger another.
I also discovered the value of Send & Wait for Reply widget in Studio. While I attempted to ditch Studio altogether, I thought ~~it was quite a bit of work to build capabilities that saves a state of a request and wait for x hours to pick up the workflow.~~ Edit (4/23): Pro tip: State can be maintained by using cookies!
Because of the first limitation, I either have to build a single Flow that has 5+ branches (more when I want to expand on trigger keywords), or I have to handle the trigger keywords parsing myself. Good thing is that I can trigger a Flow via REST API, so I went with handling my own keyword-trigger management.

Edit (4/18): Just posted a second post with more details on managing Flows.