How I Built my Side Project and Got 31,000 Users the First Week

I‘ve always been a tinkerer. Ever since I learned to code, I‘ve been fascinated by the idea of taking a concept from inside my head and turning it into something real that people can use and interact with.

Over the years, I‘ve built dozens of side projects, most of which never saw the light of day. But recently, I launched a simple tool called Screely that allows you to instantly turn any screenshot into a beautiful mockup. To my surprise and delight, it took off like a rocket, racking up over 31,000 users in the first week!

In this post, I‘ll take you behind the scenes of how I built and launched Screely, sharing everything from the initial idea and tech stack to my launch strategy and the aftermath. As a full-stack developer, I‘ll also dig into some of the code and architecture that powers Screely.

Whether you‘re an indie hacker, startup founder, or just someone curious about building products, I hope this post gives you some inspiration and actionable insights for your own projects. Let‘s dive in!

The Idea

Like many developers, I‘m an active participant in several online communities and group chats for designers and programmers. One common thing we do is share screenshots and mockups of the UIs and designs we‘re working on to get feedback or just show off what we built.

I started to notice that most of the screenshots being shared were pretty basic – just a raw screen capture dropped right into the chat. But one guy‘s screenshots always stood out. They looked like professionally designed product mockups you‘d see on Dribbble or Behance.

Curious what his secret was, I asked him how he made his screenshots look so good. Turns out he was importing them into Sketch, placing them in a premade device frame template, and exporting the final composited image.

That seemed like way too much work to go through just to share a quick screengrab, but I loved the end result. I wanted a way to get the same effect quickly and easily without needing a designer. I figured other people might want that too.

I scoured the web for a simple tool that could automate this process and allow me to make similar mockups in just a few clicks, but I couldn‘t find exactly what I was looking for.

That‘s when I realized I could probably build it myself! As a full-stack developer, I had all the skills needed to create a web app that could generate device mockups from screenshots. The more I thought about it, the more excited I got. I knew I had to build it!

Defining the MVP

With the core problem and target user in mind, the next step was to spec out a minimum viable product (MVP). For those unfamiliar, an MVP is the simplest version of your product that still delivers core value to users. It probably won‘t have all the features you envision, but it solves the main problem and lets you start testing your idea with real users.

For Screely, I imagined an MVP would cover the following 4 steps:

1. 📸 Upload – Users can select and upload a screenshot (PNG or JPEG format)
2. ✨ Customize – The screenshot is automatically placed in a device frame mockup with options to change the device and background color
3. 💾 Download – Users can download the generated mockup image
4. 🔁 Reset – With one click, users can reset and create a new mockup with a different screenshot or options

I intentionally kept the scope small and focused. There were plenty of other features I considered including even in the MVP, like more customization options, templates, drag-and-drop, and the ability to share mockups directly to social media. But I ruthlessly cut anything that wasn‘t absolutely essential to solving the core problem.

Deciding what to cut is one of the hardest parts of defining an MVP, but it‘s also one of the most important. Scope creep kills projects, especially when you‘re working solo. So be fierce about cutting scope that isn‘t essential.

Tech Stack and Architecture

With the MVP in hand, it was time to start thinking about implementation. I needed to pick a tech stack and design an architecture that could bring this thing to life.

For the frontend, I decided to go with my tried and true stack of HTML, CSS, and vanilla JavaScript (ES6+). No framework necessary – I wanted to move fast and keep things simple. For layout and styling, I‘d just handcraft artisanal, organic, bespoke CSS to fit the design. I chose Parcel as a lightweight zero-config build tool.

[ARCHITECTURE DIAGRAM]

On the backend, I planned to use Netlify Functions to handle screenshot uploads and image processing. I‘m a huge fan of the JAMstack architecture and serverless functions in particular. They allow you run server-side code in a scalable, affordable way without managing infrastructure or complex deployment pipelines.

With Netlify, I could write my functions in plain JavaScript (Node.js), and they would be automatically deployed and invoked whenever an HTTP request is sent to the function‘s URL. No servers to manage, no scaling to worry about – just upload the code and let Netlify handle the rest.

[CODE SNIPPET – NETLIFY FUNCTION]

For actually generating the mockups, I chose to do it all client-side right in the browser. There are a few different approaches I could have taken, but I landed on using SVG to create the device frames and CSS to position the screenshot and apply effects like shadows and backgrounds.

One advantage of SVG is it can scale to any resolution without losing quality. I wanted Screely mockups to look just as crisp on a 4k monitor as on a smartphone. Also, by offloading the image compositing to the client, I could reduce the load on my serverless functions and keep everything snappy.

[CODE SNIPPET – SVG DEVICE FRAME]

The final piece of the architecture was deployment and hosting. Again Netlify came to the rescue – all I had to do was connect my Git repository and they took care of the rest, automatically building and deploying the frontend and serverless functions every time I pushed a new commit.

Building the MVP

With the tech choices made and the architecture laid out, it was time for the fun part – building! I initialized a new repo, created a package.json, and started hacking.

I didn‘t worry too much about design at first and just coded up the basic flow with unstyled HTML. In about an hour I had something working – you could select a local image, see it appear on the page in a device frame, and download the resulting mockup.

[GIF OF BASIC FLOW]

It was pretty crude, but proved out the concept and gave me a foundation to start layering on additional features and polish. I started by creating a few different device frame SVGs and adding controls to switch between them.

Next I tweaked the CSS to position the screenshot within the frame, blurring and darkening it slightly to make it look more like an actual device screen. I also added a slight shadow behind the device to give it that floating 3D effect.

For the background, I used the HTML color input to create a color picker and wired it up to update the background dynamically as you choose different colors. Eventually I added support for gradients and images too.

[GIF OF COLOR PICKER]

The most complex part was the image compositing to generate the final mockup that could be downloaded. For this, I used the wonderful html2canvas library which allows you to take a "screenshot" of any web page or DOM element and get back a canvas with the result.

When the user clicks download, I use html2canvas to snapshot the current mockup and get a canvas element with the composited image. Then I convert that canvas to a data URL which I set as the href of a download link and programmatically click it to trigger a download of the PNG file.

[CODE SNIPPET – DOWNLOAD FUNCTIONALITY]

After a couple more hours of work, I had a fully functional MVP! It definitely wasn‘t perfect – there were still plenty of bugs to iron out and features I wanted to add. But it covered the key points I laid out in my MVP spec document. Most importantly, it solved the original problem and was ready for real users to start kicking the tires.

Preparing for Launch

With an MVP ready, it was time to start thinking about the launch. I‘m a big believer that launching is not a one-time event, but rather an ongoing process that starts the moment you begin working on an idea. Throughout the build process, I was sharing updates and progress on Twitter to my modest following of mostly developers and designers.

The goal was to build in public, get early feedback as I built, and start generating some interest and anticipation for the eventual launch. This definitely helped validate that I was solving a real problem and get some early users poking around the MVP.

[TWEET SCREENSHOTS]

To get ready for a more official "launch", I purchased a domain (screely.com), created some cover images and thumbnails to use on social media and product sites, and set up a Mailchimp landing page to capture emails.

I also spent some time writing a launch announcement blog post, polishing up the copy on the site itself, and setting up analytics so I could measure how the launch performed. I‘m a huge fan of Plausible for lightweight, privacy-friendly analytics.

[SCREENSHOT OF ANALYTICS DASHBOARD]

The very last thing I did before starting the official launch sequence was add a chat widget to Screely using Upscope. I cannot overstate how valuable this was for user feedback and engagement! Within minutes of launching I had users messaging me with bug reports, feature requests, and general feedback on the product.

The Launch

For the actual launch, I decided to focus my efforts on two main channels: Product Hunt and Hacker News. Both are extremely popular for launching new apps and side projects, and I was an active user of both.

I crafted a post on each focusing on the key value prop and benefits of Screely, along with some eye-catching visuals and GIFs showing it in action. On Product Hunt in particular, it‘s essential to have a complete and engaging product profile as it‘s very much a visual platform.

[SCREENSHOT OF PH AND HN POSTS]

I launched first on Product Hunt at midnight PST so I would be included in the next day‘s daily email. I rallied some friends and fellow makers to upvote and leave comments to help gain some early traction.

Things started off a bit slow, but after a few hours Screely started climbing the ranks. By mid morning it had cracked the top 5 products of the day, and by afternoon it hit #1! It stayed there almost the entire rest of the day, collecting over 1500 total upvotes.

[SCREENSHOT OF PH #1]

Meanwhile over on Hacker News, things were a bit quieter. I posted around 9am PST and only saw a trickle of upvotes and traffic for the first few hours. But around lunchtime, something magical happened – Screely hit the front page of HN!

It stayed on the front page for several hours, peaking around #11 and bringing in a flood of traffic. All told, the HN post drove over 10k uniques to Screely in a single day.

Going Viral

The beautiful thing about launching on popular platforms like Product Hunt and Hacker News is that if you do well, you start to get picked up and shared in other channels too. Sort of like a benevolent virus spreading across the internet.

As Screely started picking up steam on PH and HN, the "virus" started spreading:

• 🐦 It got tweeted by influential accounts like @DesignerNews (165k followers) and the @ChromeDevTools team (40k followers)
• 💌 It was featured in email newsletters like Sidebar.io and Web Tools Weekly
• 📝 It was written up in blog posts on Codrops, Web Designer Depot, and more
• 📺 People started recording tutorials and demos on YouTube showing how to use Screely

[EMBED TWEETS, NEWSLETTER SCREENSHOTS]

This "viral" spreading brought in thousands of additional users from all over the world. All told, in the first week after launch, Screely racked up:

• 👩‍💻 31,298 total users
• 📸 65,081 mockups generated
• 🌎 153 countries represented
• 📈 39,241 unique pageviews
• ⬆️ 1523 upvotes on Product Hunt (#1 product of the day)
• 🔝 11 hours on the front page of Hacker News
• 🐦 461 tweets
• 📥 649 email subscribers

[SCREENSHOT OF GOOGLE ANALYTICS]

Lessons Learned

Needless to say, the launch exceeded my wildest expectations! Screely started as a tiny side project, and a week later it had been used by over 30k people all around the world.

There‘s nothing quite like the feeling of seeing people use and get value from something you‘ve built. As developers, we have the power to create things that solve real problems and make people‘s lives a little bit easier or more enjoyable. It‘s a magical thing.

Here are a few key lessons I took away from building and launching Screely:

1. Solve your own problems – The best products often come from scratching your own itch. I built Screely because I needed it, and that‘s how I knew others might need it too.

2. Define a tight MVP – One of the hardest parts of any project is defining a lean, focused MVP and avoiding scope creep. Be ruthless about cutting features in the name of shipping quickly.

3. Build in public – Share your process and progress from day one, even before you launch. It helps validate your idea, gathers early feedback, and starts building an audience for your eventual launch.

4. Launch before you feel ready – No product is ever perfect, and you can always iterate based on user feedback. The most important thing is to ship and get real users in front of your product.

5. Harness the viral launch platforms – Platforms like Product Hunt, Hacker News, and Reddit can drive massive traffic if you do well. Optimize your posts for each platform and rally some early supporters.

6. Capture emails from day one – The people using your product at launch are your earliest evangelists. Give them a way to stay connected through email or social media so you can update them as you build.

7. User feedback is gold – Read every piece of user feedback you get, both positive and negative. There‘s no better way to prioritize features and fixes than listening directly to your users.

At the end of the day, the success of your launch comes down to building something people want. It doesn‘t need to be fancy or complicated – Screely is a super simple product that solves a single pain point. But it resonated with people because it made their lives a little bit better.

So whether you‘re a developer, designer, or indie hacker – find a problem, build a solution, and share it with the world! You never know what might happen.

Happy shipping! 🚀

If you enjoyed this post, I‘d love to connect with you on Twitter where I‘m always sharing what I‘m working on and connecting with other builders. And if you want to try Screely yourself, head on over to screely.com and let me know what you think!