I had a folder of side project ideas that stared at me every time I opened my laptop. Most of them were big, ambitious, and required months of work I did not have. One Friday evening, I decided to try something different. Instead of planning, I would build and sell the smallest useful thing I could imagine in a single weekend. No excuses, no feature creep. Just 48 hours from a blank directory to a product someone could pay for. This is the story of what I built, how I sold it, the mistakes that almost derailed everything, and what the experience taught me about shipping software that actually earns money.
The Idea That Fit in a Weekend
I needed a simple uptime monitor for my other side projects. The existing tools like Pingdom and UptimeRobot were either too expensive or too complex for my needs. I just wanted to know when a single endpoint went down and get a text message. That was it. I figured other solo developers might want the same thing, a dead simple uptime monitor that was cheap and did exactly one job. I named it Pinger.
I set strict constraints. Pinger would monitor one URL per user. It would check every five minutes from a single server. If the check failed twice in a row, it would send an SMS via Twilio. That was the entire feature set. No dashboards with graphs. No multi-channel alerts. No team management. I wrote those constraints on a sticky note and stuck it to my monitor. Whenever my brain tried to suggest “what about email alerts,” I pointed at the note and said no. That note saved the project.
Friday Night: The Planning I Allowed Myself
I did not write any code on Friday night, but I let myself plan. I sketched the database schema on paper: a users table with email and password hash, a monitors table with a URL and a status field, and a payments table for Stripe records. I chose the tech stack: Node.js with Express, SQLite for the database because it required zero configuration, plain HTML with server-rendered templates via EJS, and the Stripe API for payments. I picked a $6 per month VPS provider I already used. I set up the domain pinger.io on Friday so DNS would propagate by Sunday. That was the only head start I gave myself.
Saturday Morning: The Core Loop in Four Hours
I woke up at 6 a.m., made a pot of coffee, and started coding. By 10 a.m., I had a basic Express server running with a SQLite database and a monitors table. I wrote a small script that fetched a URL using the built-in Node.js https module, checked the response status, and updated the database with a timestamp and a status of “up” or “down.” The check ran on a simple setInterval loop inside the Node process. It was crude. It would not scale to thousands of URLs. For a weekend project, it was good enough.
The first time I ran the monitor against my personal blog, it worked perfectly. The second time, it reported a false positive because the request timed out on a slow DNS resolution. I increased the timeout from 5 seconds to 15 and added a retry count of two before flagging a site as down. That tweak took twenty minutes and eliminated most of the noise. I also wired up Twilio using their Node.js library. When a monitor’s status flipped from up to down after the retry threshold, the system sent an SMS to the user’s phone number stored in the database. The first test SMS arrived on my phone, and I felt a genuine thrill. The core product existed.
Saturday Afternoon: A Dashboard, a Signup Form, and the First Panic
I spent the afternoon building the web interface. It was brutally simple: a signup page with email, password, and phone number fields. A login page. A home page that showed a list of monitors with a green or red dot. A form to add a new monitor with just a URL field. I used EJS templates and no client-side JavaScript beyond a small script to confirm deletions. The CSS was about 50 lines of vanilla styles. It looked like a developer built it, because one did, but it was clean and functional.
At 4 p.m., I hit my first panic moment. I realized I had not thought about how the monitoring loop would handle multiple users with different check intervals. My setInterval ran a single loop that checked every URL every five minutes, but the array of URLs was hardcoded during development. I needed to dynamically fetch monitors from the database and distribute checks without overlapping. I rewrote the loop as a recursive setTimeout that queried the database for the next monitor due for a check, processed it, and then scheduled the next tick. It was not elegant, but it avoided hammering all URLs at once. This refactor cost me two hours I had not planned for, and by 6 p.m. I was behind schedule.
Sunday Morning: The Payment Integration That Almost Broke Me
Sunday was for Stripe. I had integrated Stripe before, so I thought it would take a couple of hours. I was wrong. I decided to use Stripe Checkout, which redirects users to a Stripe-hosted payment page. Setting up the session creation endpoint in Express was straightforward. Handling the webhook to confirm a successful payment and activate the user’s account was not. The webhook kept returning 400 errors because I had misconfigured the Stripe webhook secret in my environment variables. I spent an hour and a half debugging this while my test payment attempts piled up in the Stripe dashboard.
I also had to build a subscription management page where users could cancel. The simplest path was to let Stripe handle subscription management via the customer portal, but that required another session API call and more configuration. I eventually got it working by lunchtime, but the integration was held together with hope and console.log statements. The payment flow went like this: user signs up for a free 7-day trial, they add a monitor, and at the end of the trial, Stripe would attempt to charge the card. If payment succeeded, the monitor kept running. If not, the monitor was paused. That logic took the rest of the afternoon to wire up and test.
Sunday Evening: The Launch and the DNS Disaster
By 6 p.m., I had a working product. The signup flow worked. The monitor loop ran. The SMS alerts fired. The payment integration was functional if fragile. I deployed everything to the VPS, pointed the domain, and opened a bottle of water to celebrate. Then I tried to visit pinger.io from my phone and got nothing. The domain had not propagated yet, despite being set up on Friday. I had used the wrong nameserver settings, and my registrar was still pointing to a parked page. I fixed the settings in a panic, but DNS propagation meant I would be waiting hours. I ended up testing the live site using the server’s IP address directly, which worked but made me sweat about SSL certificates and mixed content warnings.
At 10 p.m., the domain finally resolved. I posted a short announcement on a few indie developer forums and went to sleep, not knowing if anyone would sign up. The launch was not on Product Hunt or Hacker News. It was a quiet release, and that was intentional. I wanted to see if the product could attract a few paying users without a major launch effort. I woke up Monday morning to three signups. One had already added a monitor. It was a tiny number, but it meant the system worked from end to end, and a stranger on the internet had trusted it enough to enter their phone number.
The First Week and the Uncomfortable Profit
Over the first week, Pinger gained 14 signups. Two of them entered payment details when their trials ended. At $5 per month per monitor, I was making $10 in monthly recurring revenue. That number is laughably small. But it covered the VPS cost and most of the Twilio bill. I had built and sold a product in a single weekend that was, technically, profitable from week one. That felt like a milestone, even if it was a tiny one.
There were issues I had not anticipated. One user’s URL was a slow API endpoint that took 20 seconds to respond, and my monitoring loop hung on it, delaying checks for other users. I added a hard timeout and moved to a worker queue later, but during that first week, I manually restarted the server a few times. Another user entered their phone number with spaces, which Twilio rejected silently, and their SMS alerts never fired. I added phone number formatting to the signup validation after that bug report. These were small fixes, but they reminded me that a weekend project is a house of cards that needs constant shoring up if you want to keep it alive.
What I Learned About Shipping Fast
The weekend constraint forced clarity. Every time I considered adding a feature, like a dashboard with charts or a multi-user team system, I had to answer the question: can this be built and tested in the time remaining? The answer was almost always no. The result was a product that did exactly one thing and did it reliably enough. Users seemed to appreciate the simplicity. One early customer emailed me to say they loved that Pinger did not have a bloated interface. That feedback validated the approach more than any revenue number.
I also learned that the technical side of a Micro SaaS is often the easy part. The hard part is the operations: DNS, SSL, payment webhooks, SMS deliverability, error monitoring. I spent almost as much time on those operational details as I did on the core product logic. If I were to do this again, I would use platforms that abstract away the operational complexity even further, like a serverless function for the monitoring loop or a fully managed payment page that does not require webhook handling.
What I’d Do Differently
The weekend was a success by my own definition, but there are several things I would change.
I would validate the idea with a landing page and a fake payment button before writing a single line of code. I spent Saturday morning building a monitoring loop that might have had no demand. A simple page describing Pinger with an email signup and a “start trial” button that led to a typeform would have told me whether anyone cared. I could have gathered a hundred emails in a day and then built with confidence. Instead, I built first and hoped.
I would charge from day one with no free tier, only a trial. The 7-day trial was generous, but it meant I spent the first week supporting users who might never pay. If I had required a credit card upfront with a clear cancellation policy, I would have filtered for serious customers and reduced my support burden. Free users are not customers; they are prospects, and they consume time that paying users deserve.
I would preconfigure the operational boilerplate before the weekend started. DNS, SSL, Stripe webhook secrets, and monitoring environment variables ate hours that should have gone into the product. A pre-built template with these details ready to go would have saved me the Sunday night scramble. I now maintain a personal “SaaS starter kit” that is just a Docker Compose file with a basic Express app, a database, and preconfigured environment variables for Stripe and Twilio. It cuts the setup time from half a day to thirty minutes.
Is a Weekend SaaS Right for You?
Building a Micro SaaS in a weekend is possible, but only if you are ruthless about scope. The product must do exactly one thing. You must be comfortable shipping something that is not polished. You must accept that the first version will have bugs and that your early users will find them. The reward is a deep lesson in product discipline and the possibility, however small, of a recurring revenue stream that begins from a single focused sprint.
Pinger is still running today. It monitors about 40 URLs for 12 paying customers. I have not added a single new feature since that first weekend, and I have no plans to. The code is ugly. The dashboard is plain. But it works, it pays for its own infrastructure, and every month it reminds me that shipping fast and charging early is not just a mantra. It is a viable way to build software that people value.
