KIBI.ONE PRESENTS…

How to Build a SaaS Product in 30 Days Without Code

“The concept of keeping the project’s complexity manageable is really important to us. We’ve found over the years, there is a bit of a “sweet spot” in terms of platform complexity. You need complexity to be there, to some degree, to keep competitors at bay, but you don’t want to focus on ideas that are so complex, they will take you 2 years to build.”

Kibi.One is a no-code SaaS incubation program focused on helping non-technical founders build software companies. Visit our homepage to learn more about our program.

Building a SaaS Product in 30 Days Without Code

I built a SaaS in less than 30 days without code and in this tutorial I’m going to walk you through my build processes. We’ve also created a video which walks you through our build process, which you can watch below.

Now, if you don’t know, we’re Kibi.one, a no-code SaaS incubator program that teaches non technical founders, who to build technical products, like the product featured in the video above.

Now, over the years, we’ve managed to build a portfolio of micro startups that are currently valued at over a million dollars. So if you’re interested in taking your no code skills to the next level to learn not only how to build, but also how to monetize your products, then I’d suggest you check out our main page to learn more.

So let’s jump in and talk about this project in a bit more detail.

Scope – Keep it Small

So first of all, when we launch new projects, the goal is to generally keep the scope small.

We try to focus on doing one thing really well, rather than trying to do many things at once.

So currently, scribble is really just focused on being an organization and productivity tool for writers. Whenever you’re working on a creative projects, there is so much you need to keep in your head. The creative process can feel really messy and disorganized and it’s often hard to separate yourself, as the creator, from that mess. So I wanted to build something that allowed writers to organize their thoughts in a really logical and well organized way.

But as you can see, with Scribble, we’re not trying to be a publishing platform, and a marketplace and all of the different tools that writers need. To start out, I really just focused on productivity and organization tools.

Better serve an Overserved Market

This brings me to my next point which is to focus on better serving an overserved market. Now, currently there are a lot of writing tools online, many of us use tools like google docs for example, each day, but they don’t cater specifically to the specific creative needs of authors. Google docs is as valuable to a general audience, and that audience is huge. But because they target to the masses, they miss niche needs of specific niches. So we can create an application which addresses those specific needs and pain points and therefore our application will speak to that smaller, but still sizable market. So going into this build, this is what I knew I wanted to do… to just focus on this one very specific market.

Leverage Existing Assets

Because we launch so many products we can reuse digital assets which we know work. For example, the homepage of scribble is the same homepage we use for many of our digital products. We simply swap out the copy and change around some images, but that takes about a day. If we had to design everything from scratch, it would add another week onto the process. So wherever possible we try to reuse assets.

Plan on Paper Before Building

One of the most important things we do before we build anything is we plan everything out on paper before. This helps us paint a general picture in our mind regarding how the app logic and navigation will work.

For some reason though, whenever I’m working with paper, I can never get everything out. What I put on paper is never the final product. What I put on paper tends to be a very broad sketch and solid skeleton for the final product, but I tend not to think of the finishing touches until I’m editing digitally. But I find if I don’t sketch the application out visually on paper beforehand and I just jump into bubble and start building, then I get lost and confused easily. So pre-planning on paper has been essential for me to be able to move quickly.

Keep Complexity Low

The concept of keeping the project’s complexity manageable is really important to us.

We’ve found over the years, there is a bit of a “sweet spot” in terms of platform complexity. You need complexity to be there, to some degree, to keep competitors at bay, but you don’t want to focus on ideas that are so complex, they will take you 2 years to build.

This is especially true to solo builders or small teams like ours where you have to get your product to market quickly to see if you’re even on the mark. There is nothing worse than spending 2 years building, only to launch and find out that you’re way off.

Again, we stage our builds, so we can always start out with a simple, more scaled back version of our final vision, but this staged approach allows us to massively hedge risk around product / market fit.

We’ve been wrong before, and in my opinion, as long as you didn’t spend half of your adult life building something that nobody wanted, you can walk aways with your head up still.

Stick to Simple Milestones

When it comes to application planning, at Kibi.one we use agile development methods, but it can still be a challenge as a small team to hit your development targets on schedule.

In the past, and even still to some degree today, I tend to overestimate what I’m capable of doing as just one person within a day. But wneverver I’ve decided on pushing and idea out of the idea conceptualization stage and push it into development, I focus on completing one element or sub-feature per day. Again, because I’m keeping the scope small, there are not many features in the first place. The idea isn’t to have many features that cater to everybody, but a smaller number of really high impact and helpful features.

So just in terms of the quantity of features, there are usually not that many. So I can just focus on making each feature as good as it can possibly be.

For example, in Scribble I built a character template where writers can map out their characters and their character backstories. So one day, I’ll dedicate my day to this one small feature here which is this list of icons and their placement on the popup. I’ll need to design the icons, shrink them down, create these groups, within bubble each of these tabs has a state and it’s not hard work to get this complete, but it’s time consuming. Everything has to be lined up properly and placed in the right layer, then you have to enable autobinding for each element and then set the privacy settings. Not hard work, repetitive and time consuming.

In another example, I wanted to have two progress bars. One which monitors chapter progress and one which monitors overall book progress. So I would dedicate my whole day to sorting out these two progress bars.

But what I find is that focusing on just doing on these simple things, a couple of things happen. First, if an obstacle ever arises, which happens often, you have the entire day to troubleshoot. However, when you assume something is easy so you think it will only take you 2 hours, but then you get thrown a roadblock your entire weekly or monthly schedule gets thrown off course.

And this progress bar is a great example. Because this is a really easy feature to design. But what I didn’t realize is that when I set up a count to monitor the number of words within the text editor section, the word counter was counting formatting as well. For example, If I bolded a title it would count the formatting as their own words. So if I wrote two words, four would be counted. If I changed the font, the font tags would be counted too resulting in two words equally six. It was a mess.

So I had to think about ways around this. And luckily, for this 2 hour job I had all day to figure this out. So what I ended up doing is using regex within Bubble.io to filter out certain character patterns from my word count. But it took me some time to think about this solution.

On the other end of the spectrum, when you underestimate what you can do in a day, you can always put tomorrow’s work on your plate today. So if you don’t run into obstacles, then you can get more done that day than you thought you could, which is hugely encouraging.

Focus on Creating a Great V1

The next thing I did was I just focused on getting up a v.1. I just need my first version to be the best first version it can be.

Your first version will neve have all of the features you want on launch day, but you can chip away at them over time. In fact, over on scribble, I have a milestone document with the features that I want added over time. This helps me maintain a vision for my product in the future as well.

Not only that, but in my experience, my job is always best done when I get the foundation up, the V.1, and then I open myself up to user suggestions. So this leads me to my next point.

Systems to Take Customer Feedback From Day 1

Remember who you’re building this for other people, even if you started the product to be able to solve one of your own pain points. This is a great place to start, but from there, it needs to evolve into something bigger.

So when we launch SaaS products, from day 1 we always have a system to collect user feedback which helps us improve our V.1 as well as gives us a wide assortment of feature ideas for future versions.

So for example, over on scribble, we have a “suggestion box’ page where people can add their software suggestions and other users can vote on them. While this page is never popular early on, within 4 – 12 months it often ends up being one of your best sources for feature ideas.

A Firm Launch Date + 30%

Lastly, set a fim launch date in your mind, at 30% to it and then don’t miss it. Again, if you break the big project up into smaller reasonable daily chunks, it will be very hard to miss your target.

With Scribble, I would finish at the end of March, so my final date was set to around mid april. But I had no setbacks, so I was able to hit my march deadline. Now there were two times when I really struggled with more complex parts of the app. One night I stayed up until midnight until I figured it out, and other times I couldn’t figure it out on the day I had planned, so I worked on a weekend day which I normally don’t do to make up for the lost day.

Conclusion

So if you’re interested in learning not only how to build, but also how to market no-code platforms like this and you don’t want to have to figure things out on your own in a haphazard and poorly organized way, then please head over to kibi.one to learn more about our no-code SaaS incubator course where we lay out both the SaaS product building process as well as the marketing process in an easy to follow and outcomes based manner.

Kibi.One is a no-code SaaS incubation program focused on helping non-technical founders build software companies. Visit our homepage to learn more about our program.

Build SaaS Platforms Without Code

Kibi.One is a platform development incubator that helps non-technical founders and entrepreneurs build software companies without having to know how to code. 

We're so sure of our program, that if it's doesn't generate a positive ROI for you, we'll buy your platform from you. Watch the video to the right to learn more.