This is the story of how I built a SaaS product—Propfire—without being a developer, or hiring one. The reason I’m writing this is to give non-technical founders a blueprint to follow (or at least some hope) in their own startup journey.
Now, the first step to any development process is obviously having the idea of what you want to create. But for the purposes of this post I’m going to skip over why I chose to build Propfire and stick with the process of developing the actual software. You can read about why I decided to create Propfire in a market already crowded with competitors here.
Who am I
Before I dive into the details of my development experience, I need to tell you a bit about who I am and the skills I brought to the table when I began my development project.
For the last seven years I’ve been building WordPress websites, and providing SEO and content marketing services for companies. The website development part of my services entails working with a few professionally designed templates that I’ve gotten very familiar with over the years, and modifying them with basic CSS.
If you’ve ever worked with WordPress you know that you do not need to have any development or coding skills to create a beautiful website. All you need is the ability to organize information (no simple task) and work with whatever website building engine your particular template provides. There are even tools that will generate custom CSS code without you having to know how to write it.
But I don’t want to portray myself as a total coding ignoramus. Back in the years 1999–2000, I had learned how to code html from a book and then rode the dot com wave to get jobs at a couple of internet companies (which are long gone) where I had the opportunity to perfect my html and learn ASP (not the same as ASP.net) and some SQL (on the job). For those of you who don’t remember ASP, it’s very similar to PHP.
While I definitely didn’t become a coding expert working at those companies, I did have the opportunity to learn from more experienced developers the basic structure of a web app: how to set up database tables; how to move data from a web page to the database; and how to extract and display data back on the page. Once you know how to pass information to and from web pages and into and out of a database, you’re well on your way to creating a data-driven web app.
Structure vs Implementation
The most important part of the development process is understanding the flow of your application. You need to map out exactly what happens on each page or screen of your app. Once you know what data you want to get, manipulate, and display, and where you want to do that, the task of writing the code to make it happen is something that you can either figure out yourself or pay someone a relatively small amount to do for you.
The most expensive (and probably the least effective) way of developing an application as a non-developer is to come up with an idea and then hire a developer (or team) to turn that idea into a functioning product—unless you just want to copy an existing product. For example, if you decide you want to create a Tinder clone with your own branding, you can find developers who can do that pretty efficiently by simply copying the original. That’s because the structure and flow (and UX) of the app already exists—and that’s the hard part.
A lot of the time I invested into developing Propfire was spent figuring out the UI (user interface) and UX (user experience) of the application. I wanted to create a way for a user to build a proposal faster and more intuitively than the competitors’ ways (they used design templates).
I began by drawing the individual screens of my app on sheets of paper (one screen per sheet) and put them in order. Then I went through each screen as a user (over and over) to determine the most user-friendly and intuitive experience.
I’ll admit that my knowledge of basic database table structures helped by through this phase; because as I was moving through the screens I was also mapping out how the information being entered would be efficiently stored and accessed.
Understanding how to store data in a relational database has more to do with organizing information than with coding. You don’t need technical skills to organize information. But you do need a basic understanding of how a database and data tables work, which I got from a book around twenty years ago. The principles of storing and managing data haven’t changed much, surprisingly.
You do not have to be a database guru to create the data tables for your app. All you need are the basics, which you can learn from books, tutorials, or online course. Again, database design requires the ability to organize information—not technical or coding skills.
So up to this point, I had not written a single line of code, but I already had the the UI and theoretical functionality of my app. And like I said before, once you have this, the actual writing of the code becomes a technical task that can be outsourced or done after some education.
The type of app matters
Let’s stop for a second. I need to clarify something important.
This post is referring to an application that uses existing technology to accomplish a task. The innovation is in the design of the application: figuring out a more efficient and effective way to accomplish the desired task. That’s why the coding part of the application development is something that any skilled coder should be able to do quite easily.
However, if you want to develop new technology or a sophisticated algorithm to accomplish a complex task, then you are going to have to get expert programmers to work on developing that technology—and that’s way beyond the scope of DIY or ordinary outsourcing.
Just keep that in mind going forward. 🙂 Okay, back at it!
My plan from the start was to create an application for as little money as possible. I just wanted a functional MVP (minimum viable product) to test the market. I could always build more features after I’d found product market fit.
If I could create the flow of the application and all of the screens, I knew I’d always be able to find a developer to code it (although I never actually priced it out).
Of course, there’s a wide range in quality when dealing with developers, and the price you pay is going to be directly related to that quality. If you need a developer to do the thinking for you and create the application flow and screens, then you’re going to have to pay a lot more than if you’re just looking for someone to code up your screens.
Building without code
After a few months of thinking, mapping, rethinking, and rethinking again, I had all my screens and knew exactly how I wanted my application to work (at least version 1). Now all I needed to do is build it!
Like I said before, I didn’t have a big development budget to play with. Even if I did, I believe in the MVP model, especially since I had no idea whether people would actually want to use (and pay for) my product. So there was no way I was mortgaging the house or selling my son’s Xbox to pay a developer to create my MVP (and you probably shouldn’t either).
I needed to build Propfire, or at least most of it, myself.
How was I going to build a data driven application myself?
My first thought was to see if I could find a way to create my app without having to code at all.
In the past I had played around with a very cool program called Bubble, which according to its website “is a code-free programming language that lets you build and host web applications without engineers”. In other words, Bubble lets you build stuff visually (like using a website builder tool), while creating the actual code behind the scenes.
Sounds great, and it really is. You can create lots of very cool stuff using Bubble.
One of my hesitations in using Bubble was that you can’t modify or export the underlying code. It’s created in the Bubble framework and has to be hosted on the Bubble platform. If at some point I’d want to hire developers to improve or expand the app, they would need to rebuild it from scratch in whatever language they were using.
But this wasn’t a deal breaker for me. The Bubble folks claim to have a very stable and scalable hosting problem, and the price was ok. And if at some point my app was so successful that I needed to rebuild it, then I’d be able to afford the extra development work anyway.
The reason I did not use Bubble to build Propfire is because I found the platform to be constraining. I tried building it through Bubble, but I found that I couldn’t perform some of the data operations I needed to. Now, that could be totally my own fault for not fully understanding or implementing the Bubble capabilities; for all I know, Bubble might absolutely have the capabilities to do everything I needed to do and more.
But I did spend a decent amount of time trying to figure it out, and it just wasn’t happening for whatever reason. At the same time, I knew that these data operations could be easily done in a few lines of code.
So despite the allure of being able to visually develop an app without writing a single line of code, I opted to try it the good ol’ way—just writing code.
[Again, I don’t want to downplay the power of Bubble and other code free platforms. People have been lots of functioning apps on them and there’s a whole sub-industry of Bubble developers available to help you build yours. Depending on the complexity of your app, using Bubble or an alternative might be the smartest way to go.]
Choosing a Language
The first thing you need to code is a language to write it in. Google something like “what language should I code my web app in” and you’ll find an ongoing debate as to what language is the best, the easiest, and the neatest, etc. The bottom line of the debate is that it depends on what you want to build and what language you already have some familiarity with.
Remember how I told you that I learned ASP around twenty years ago and that it’s similar to php? Well, it just so happens that php is probably the most popular scripting language to build data driven web apps with. Some of the most famous apps built in php include WordPress (which includes hundreds of millions of websites built on the platform), Yahoo, and Wikipedia.
The reason PHP is so popular is because it’s relatively easy to learn and use. And there’s plenty of documentation and code examples available. So since I already had some basic knowledge of the language structure, I chose to go with php.
Before writing any code, you need some prerequisites to get started.
- Code Editor — All you really need to write is code is a basic text editor like textedit (mac) or notepad (windows). But if you want some help in the form of highlighting, formatting, auto-completion, and other useful tools, then you’ll need to use a code editor. There are lots of them available for either man or pc, and free or paid. I chose Visual Studio Code by Microsoft—which is the mac version (since I use a Macbook Air)—because it’s free and I liked the feel of it. You can also try Atom, which has lots of great reviews. None of these editors are going to actually write the code for you, although they’ll let you know when you’ve made an error and sometimes save you some typing by providing code snippets you can use. Don’t spend a month trying to figure out which code editor to use. Just pick one and grow to love it.
- Local Database — Since my app was data-driven, I also needed to set up a local database. The most popular choice is MySQL, which you can download for free here. The same article that showed me how to set up my local server covered the MySQL installation and the installation of SequelPro, which is a tool to manage MySQL with a visual interface.
To clarify, the development environment I just described allowed me to code and view only on my computer locally. I would eventually need to host the app with a hosting company, to get it “online”. But for the time being, I was fine working local.
I had my code editor and my local server and database setup. Now, I had to actually start writing code!
There are two parts to a web app: the functionality and the presentation. In other words, what the app actually does behind the scenes and how it looks to the user.
You can start on the functionality and leave the interface for later. I personally wanted to have a concrete idea of the app interface would look before diving into the functionality.
But building a web interface from scratch and making it look awesome (on both desktop and mobile) takes a lot of time and hard work. There’s an easier way: I found a free html web interface template built on Bootstrap.
Setting up an html template can be a bit difficult and time-consuming at first, but once you understand the basic structure and set it all up, the work is done and you’ve got a beautiful interface for your app. It’s not much more complicated than that.
After my interface was in place, I created my database. A database is made up of tables that store different data. These tables relate to each other. That’s why they call it a relational database. I can’t teach you how to build a database, but again, it’s all about organizing information, not programming or coding.
Google is the answer
While I had some basic knowledge of php, I couldn’t actually code an application from scratch. However, I could look at existing code, figure out what is was doing, and modify it.
That’s where Google came into the picture.
In theory, what I should have done was to take a course to learn how to write php code from A to Z. And I have gone through some “Learn PHP” books over the years. However, learning from the bottom up route would take me a very long time, which was something I absolutely did not want to do.
My goal was not to be become a php developer. All I wanted to accomplish was to build my app. So, instead of searching for a course or book, I went on Google and starting search for the php code that would accomplish the specific task I needed at that moment.
For specific questions, Stack Overflow, a forum where developers ask questions and other developers answer them, was a godsend. Any question I had, no matter how specific, had already been asked and answered on Stack Overflow. (Another great site with tons of code for the taking is phppot.)
It’s really quite amazing what you can find out there. A few times, I found examples of code that I could copy and slightly modify. Other times it was small snippets of code from Stack Overflow that did the trick.
The bottom line is that you can pretty much copy-and-paste your way to a complete, functioning application. All you need is: just enough knowledge and familiarity with the language; the basics of how an app works to modify the code to your own needs; and to know where to place it.
A disclaimer: I don’t want to mislead you into thinking that you can easily throw together an app by just copying-and-pasting. You can’t. You need to understand enough to know what code you need and then how to integrate it into your app. You also need to weed through a lot of search results and code that isn’t right or doesn’t work for you before you find the code that does work.
BUT—if you can educate yourself enough, you can hack together something that really works!
Putting it online
It took me about two or three months of on-and-off coding (while still doing my other digital consulting work) to complete most of the code for the app, which was still living on the local drive of my Macbook. In order to use certain online scripts, set up my registration and payment process and see how the app looked on a mobile device, I needed to move it to a website hosting platform.
There are loads of hosting companies to choose from. I use Pressable for all of my WordPress sites, including the Propfire marketing site. But since Pressable focuses exclusively on WordPress and my app wasn’t WordPress, I decided to go with Cloudways. It’s cloud based, inexpensive, and very scalable for when my app gets huge. 🤞
Cloudways also lets you easily create a staging site, which is important to have in order to test changes before pushing them directly to your live app. In other words, you write your code on your local machine, test it on your staging server, and then push it to your live server.
If you plan on charging for your app, you need a way of accepting and managing customer payments and subscriptions. I chose to use Stripe as my payment processor, but there was no way I could integrate it into my app (or even if I could, it would take me much too long to figure out how).
I found a few services that provide a ready-made integration with Stripe that you can just add to your site. I chose Servicebot (because it was the cheapest option), which lets you easily create nice pricing tables and handles the subscription registration and billing via Stripe.
Servicebot costs me $49 per month, whereas simply using Stripe is free. But I would have had to pay a developer to integrate it for me and it would have been difficult to manage on an ongoing basis. With Servicebot, I still had to pay a developer a small amount to integrate, but now I can easily change my pricing tables and manage my users and subscribers on my own. It also handles the login/registration process on the app, which is a bonus.
In general, I always try to keep things as simple as possible so that I don’t need to rely on developers for most tasks. Servicebot makes my life easier, so I’m happy to pay the monthly fee.
There are lots of other subscription management providers with different features and at different price points to choose from, so do some research before picking one.
Using a Developer
Since I mentioned using a developer to integrate Servicebot, I’ll make a couple of quick points about working with developers.
Unless you’re well-funded, you’re probably going to use a freelance developer. I found mine on Upwork several years ago when I was working on another project. He’s located in South America. I’ve also used an offshore development shop before.
I personally prefer working with a solo developer over a firm because I can communicate directly with them instead of going through a project manager or some kind of management tier. But there are pros and cons to either, so go with what works best for you.
The most important thing is to work with someone you feel you can trust.
An offshore developer is going to be much cheaper than a US based one. In some cases the cheaper price might reflect less experience or lower skill level. But there are plenty of very experienced developers, especially PHP developers, who will do an awesome job for a fraction of the cost of a US developer because of the lower cost of living in their native land (and because they really want the work). The trick is finding them, and that is often a process of trial and error or just pure luck.
When you’re sending your developer a task, you MUST include specific instructions—the more detailed the better. Some developers will be able to figure things out on their own; most will not. The best way to avoid costly misunderstandings and screw-ups is to communicate CLEARLY, preferably in writing.
A really good developer will tell you you’re goal makes no sense or won’t work as planned. Additionally, when you’re dealing with someone halfway across the globe for whom English is a second (or third) language, you have to anticipate the possibility of communication difficulties. Therefore, be extra careful when creating clear and detailed instructions.
Something else to keep in mind: you can’t expect to get an immediate answer from a freelancer in a different time zone. That’s why it’s best to be familiar enough with your code to troubleshoot in an emergency.
In my case, I’ve had to troubleshoot the few snippets of code I got my developer to write. And the few tasks I give him tend to take longer than expected. But as far as I’ve “hacked” on my own, there are still some difficult tasks that are simply beyond my experience, and I’m not willing to spend the time it would take to learn enough to do them. That’s when I’ll turn to my developer—when I simply can’t (or won’t) do it myself.
At some point, when Propfire is making lots of money, I’ll hire a good developer and fly from there. For now, I only pay for the stuff I can’t figure out on my own.
One of the things I put a lot of effort into making sure the instructions on each page were clear enough for new users to follow without asking for help. But despite all this effort, I still anticipated a lot of user questions, so I needed to create a support center.
There are several major help center software tools on the market. I chose Zoho, primarily because of its free plan. You can check out the Propfire support center here.
Then I got to work writing knowledge base articles.
Just as I was stressing about it, as if by divine intervention, Appsumo offered a lifetime deal on tooltip.io, an app that makes it super easy to add and manage in-app messages of all types including tooltips, slide outs, popups and lots of other types. Huge problem solved, for only $49 (lifetime). Thank you Appsumo!
If you’re building or planning to build something, you should definitely be following the Appsumo deals because you’ll find some real gems which will (at some point) make your life easier for a heck of a lot less than you would otherwise have to pay for them.
Taking your app live might be the end of your development journey… well, at least “phase one” of it. Unless you’ve performed the most thorough testing possible, you’re going to find bugs and things that seemed to work really well at the time, but now don’t seem that great anymore and need to be changed.
You also should always be trying to improve your product. New use cases will arise that will motivate you to tweak the way the app works. Maybe that tweak will turn into a major change.
And now that the development is done for a while, the real hard work begins: marketing (i.e. getting paid users!). I’ll be writing another post about what I’m doing in that regard real soon.
I hope this post has at least given other non-technical Indie Hackers the courage and motivation to try their hands at developing their own SaaS product.
Feel free to reach out with questions in the comments below. 🙂