How do you Learn to Build Substantial, Real-World Apps?

Building a real-world application requires a lot of work and a lot of skills other than technology if you want to set up something sustainable. Marketing, Sales, Analytics, and even Accounting are skills needed next to the engineering side to build a real-world application. A real-world application involves a product or app that has some users. But the good news is that you can be a user as well. That should be easy, right? But now the problems arise. What should I build that I will use myself and how to create it? This blog article will set some light on this process by showcasing how I deal with several steps to building real-world apps. As a small reference, I built caseconverter.pro, a simple case converter, think of PascalCase to camelCase, and getworkrecognized.com, a Work Achievement Tracker with the functionality to create Brag Documents or Self-Reviews, over the last year. If I was able to create these two apps or products, you can do so too!

Finding a Problem is difficult?

I have seen many Software Engineers failing with this. I think it is buried in our mentality sometimes. Software Engineers are different from the common population. Some like to focus on the coding part, and others love to focus on the product. Gergely Orosz wrote an excellent article about the Product-minded engineer and how they differ from "classical" software engineers. I observed that these Product-minded engineers have an easier way to find product opportunities. But that is just my observation.

So what is my process of finding problems to be solved? That’s quite easy. First of all, I do not actively look for a product opportunity. I just live my normal life. I have a full-time job. And you will see so many problems at any job. Try to observe your current job and see if you do any repetitive tasks. For me, an example was creating the Self-Reviews of myself at work. I could not remember what I did the last six months and needed to look up everything with the funky JIRA search. It did not go so well, to be honest. Consistently tracking your work and tagging the work achievements should work. So I built an app for this.

A secret tip of mine: Check the Google Sheets or Excel tables you have at your work and see if it could be built with an easier-to-use interface like a web application. And if your company has this problem, other companies likely have these problems as well. But this should get figured out later.

Normally, I keep track of these things in a simple Google Keep Note. Just write down the problem in a simple one sentence. Write the ideas down for some time, and you should have at least ten ideas written down to continue. Now it is a question of what to choose. More on this later.

Alternative ways

There are, of course, many alternative ways on how to find ideas. What I have seen working as well is checking existing applications. For example, you can choose one of the apps in the App or Play Store and check the bad ratings and try to look for something that did not work for the customer. Maybe the product was wrongly targeted, or the functionality is just bad. Figure this out and write down the idea in your backlog of ideas.

Another possible idea-finding practice is to be on the lookout of local startups in other regions or languages. For example, there is a product called The Church Co, which is a website builder for churches. They are on Indiehackers and have quite a huge amount of revenue. That could be applied to local markets like Germany, Austria, Switzerland, or others as well. Just localize the idea and bring it online. Products like these exist in masses already, but it does prohibit you from trying. Another example could be Xing. It is the german LinkedIn and is even registered on the stock market.

Building the Startup vs the App?

One of the expectations you should set before this whole process is if you want to build a proper startup or just a side project. You can switch, of course, but the initial affords might be given to different topics depending on which path you choose.

The Business Route

Once you have found a problem, you need to validate it. Everyone loves money, so you need to think about monetization now. Your idea needs to generate money, and that is why you need to validate potential monetization touchpoints. That can be super different for every use case. Most of the products we build these days are subscription-based businesses. But it could be different for anything. To validate this behavior, you can throw a simple landing page together. The landing page should include the simple value propositions to the customers and one call-to-action that lets users enter their email. These emails are golden. You should manually interact with them and ask more about their problems and if they are willing to pay. You will soon figure out if it is worth it to build a product around it or not. Getting initial users on your landing page is simple marketing. You won’t have a huge amount of backlinks. So try to get into communities that might need your tool and have questions regarding this. For example, with the Church Co localized copy, you could join some Facebook groups and make a simple survey to ask churches if they have a website and if they would like more functionalities. Bring them in the end to your landing page and let them enter their email.
By responding to related communities consistently, you will also get credibility in the domain. That is important. You need to build an audience you can sell to later. This process can take time. So do not give up after just a few days. Keep poking and trying. Once you validated that the idea is worth some money, you can start implementing it. The technical details will be described in the next chapter.

The technical Side Project Route

This route is the route most Software Engineers take. They do not validate their product in the first place and just build it. Maybe they will use it but no one else. That is also a win for sure but might not generate any money. Of course, the projects will look good on the resume. Especially if you have a lot of space, but otherwise it comes down to your mindset on what to focus on. Money or the cause of the application. If the money is an unimportant part for you, then just build. Success might follow if you build consistently and also start to do the Marketing and Sales afterward.

What is involved in an App or Product?

Normally an app or product consists of different things. All of them have a backend or application code and an interface. The interface can be created in different ways. A CLI or API is also just an interface, but most products have a Web-Frontend or a mobile application. If data is saved a backend is also needed for most use cases, especially databases. Typically a landing page and several other resources regarding marketing and sales are required as well. These are the basic parts that you need to get working initially to have a local development environment and a public presence.
On another note, you might need several other things like domain names, a server, the infrastructure around this, a remote database, an email, and many more things. For example, all social media accounts should be registered with the preferred name of your product app. And a lot of other things that have to be done.
Once you have figured out all components needed to build the app, we can start building the app.

Building the App

The creation of the software is probably the most important step for Software Engineers. If you have an interface, you can have a prototype for your idea. The prototype can vary from a User Interface mockup to even just a simple interview with potential customers with a hand-drawn User Interface. The further you go into the step, the more work is invested, but you will also receive more direct feedback that you can act on. In general, keep things as simple as possible. Software Engineers often try to overcomplicate things, trying to deliver a fully functioning app without validating. Step by step.

Find a Name

A name is important for every product or business. Customers identify with the product and brand of the application. A name will probably help with this. Finding the name is not hard. If you want a simple name just use the combination of the target keyword for your product and append a random animal. For example:

• SurveyAnt
• FeedbackFish
• BannerBear

And so on. There are many more examples of doing it like this.

One thing that should be checked additionally is the availability of the URL and all relevant social media channels like Instagram, Twitter, LinkedIn, and Facebook. There might be many more channels you want to have, but this is a personal decision.

User Interface Design

User Interface design involves a lot of parts. Some Software Engineers are quite good at everything and even know how to design well. I can recommend reading the book "Refactoring UI" that will give you small recipes and patterns to follow on how to create good designs.

The first part where User Interface design gets important is the landing page. Fortunately, the Open Source world delivers some landing page designs that you can copy and change a bit like:

• https://github.com/cruip/open-react-template
• https://github.com/issaafalkattan/React-Landing-Page-Template
• https://github.com/Hermanya/react-landing-page

If these do not fit your style, you can build them yourself. If you need design inspiration, you can also check dribbble. It is an excellent website to get idea inspirations (or copy the designs).

After this is completed, you can start finding the design process of your actual application. The color schema of the app needs to be decided, and several basic components can be defined. The basic components can be used from one of the open-source design systems to give you a headstart. You can find a collection on this repository: https://github.com/alexpate/awesome-design-systems

These are all the tips that should get you started. In the first place, do not focus on perfect User Experience. This includes Animations, proper layout construction, and all of the things that make the app just "pretty".

Languages

Programming languages are a big topic when it comes to projects. They define the structure of the project. How well it can be maintained over time and if it ever gets big how hard it is to find someone to contribute to the project as well.

Currently, in the software world, some languages are dominating the market: JavaScript, Java, and Python. All of them have their use cases and advantages and disadvantages. Any other language as well. So does it matter which language you choose? A possible answer to this question can be formed by asking the users of your application. Will they care what language you have written your backend or frontend in? The simple answer to this question is NO. So there are other factors that you need to ask yourself regarding the decision for a language. The most common factor in all of our lives is time. Learning a programming language is taking time more time than using a language you know already, but also brings advantages for future references like applying to new jobs and widening your horizon. The thing is, you are reading this article because you want to know how real-life apps are built. In real-life, customers want a solution to a problem and do not care what you are dealing with. Choose the language you are comfortable in the first place and build a prototype. Once getting validation, and seeing that this project could be something bigger ask yourself if there is a job market for your technology. It is far easier to find a good Java engineer than a good Clojure engineer. So try to build bits of your business in popular languages right from the start, if you know how to master these languages or build bits of the software in popular languages later.

Architecture

The architecture of every application is important, that is what they say. In reality, most customers care about:

• The solution should be available
• The product should be fast
• When they request a feature, it should be available fast

So these three things manifest in some common software concepts. The first statement probably depends on the stability of the application. It should be available 99% of the time, so customers can use it. But honestly, most of the problems you will solve currently are being solved in Google Sheets or Excel as mentioned in one of the first chapters. So, your app will be a simple CRUD application (CRUD = Create, Read, Update, Delete). Having downtimes for such apps is quite unlikely if you choose a framework that has an Object-relational mapping (ORM) like Django, Ruby on Rails, or similar. Hosting is another part that becomes important then as well. Choose a hosting provider that seems kind of stable and has a good reputation. The more they handle for you, the better it is. Heroku, vercel, envoyer, or render.com are good solutions for handling everything for you. You basically just have to create a Docker container for your application, and they will handle everything for you, super easy. If you want to go deep into managing your server or handling a lot of things yourself, which is difficult and brings its challenges, I can recommend DigitalOcean or AWS. The latter will give you even more plus points on your resume. But that’s about the availability of your solution.

Regarding the speed of your solution, do not over-optimize before anything is built. The customers simply do not care if you have replaced an npm package that saves 10kb in the final bundle if your app is small and does not have any customers.

For web applications focus on two things: image optimizations and reducing the number of SQL queries in your backend. When there are more than 50 SQL queries, for example, on a page load, try to bring the number of queries down. This normally originates from abusing your ORM. Fix these queries to follow the ORM’s standard. But more importantly, optimize the images in your web application if you built a web application. That is the most common factor why websites load slowly. For other types of projects, the possible optimizations are far less important.

Another point for the architecture is that the produced code is put in a way that new features can be added in a fast way. For this, I recommend to use not that much DRY code. Sometimes it is ok to repeat things in the first place until you know that the feature is needed. Just do not over-optimize these things. In general, keep it simple. Do not introduce microservices in the first place, do not build libraries that can be published instantly. Just build them when you know there is a definite use case.

Database

Databases are an important part of any real-world application. There are many solutions out there that can be all compared. But even here, the same thing as with languages applies. Use a solution you know and are comfortable with. You can even save data in Google Sheets (do not do this). SQL or NoSQL, PostgreSQL or MySQL. It does not matter. Just save your data. Once you get customers and get more data flowing in and out, you can rethink your database decision. NoSQL or SQL is a question every developer might ask themselves. Choose based on what kind of data you have. SQL is working better if you have a lot of structured data and NoSQL works better if you do not know the structure of the data you want to save.

Another thing happening in the SQL world is premature optimization when it comes to performance. Introducing things like database partitioning or indices. It is fine to think about these things in the first place but will they make a difference when you simply do not have enough data in your table? The first customers won’t be like wow, the page loads 3ms faster now because this table is queried so fast. So focus your time on something else in the first place.

Once, your app is growing and database performance starts to slow down, it is time to look at it again. Database performance optimizations are quite an interesting topic but dependent on the data you will look at. These techniques mostly involve partitioning and indexing of columns. Indexing of columns is quite easy and will solve almost all problems with database performance.

Deployment

The deployment of the app was touched already in a chapter before when dealing with the decision for a language. In general, make it easy to deploy. With solutions like render.com or with the guides on DigitalOcean you can copy-paste your deployment process. For most applications, that are web applications these days, multiple recipes are provided or work out of the box with render.com. You might need to learn a new technology that is Docker, but it will be worth it to make your life less of a pain. Just use services out there to deploy your application. Do not reinvent deployment.

Making the app sustainable

Creating the application is one part of making a “sustainable” app. The things that come afterward are marketing and sales. Both are skills that software engineers normally do not have. That’s also why they are completely different career paths. But you can learn, as everyone can.

Let us start with Marketing. Marketing is an ever-evolving competency. Trends are discovered. People change and strategies get refined continuously. The first thing you have to find out which channels your audience is interacting with. It could be different platforms like Social Media, some subreddit, hackernews, LinkedIn, Facebook Groups, or anything else. Once figured out try to build an audience in these niches. Post useful content not directly linked to your startup but evolve answers in your product or the blog of your product. This process is then called content creation. This can vary a lot. There are several other vectors in Marketing. You can read up a bit on the page Marketing Examples. They list various examples of how companies have done Marketing. Apply these ideas to your idea and market your app.

The other thing that is closely related to Marketing is Sales. These days it is outreach to potential customers and keeping a relationship with them. Several CRMs can support you with that, but a simple Excel Sheet helps as well. You might be not good at it but look at how other startups and products are doing Sales. A good resource for that is the Indiehackers Interviews and Podcasts that shed a lot of light on this topic.

Outlook into the future

Now you have built a sustainable app, but what now? That is something you have to decide. Scaling a product is a whole different story that I might describe in a future article. For now, I hope, I could give you some insights into the app-building process that I have used now several times to build side projects.