Building
I’ve tried building a few things over the years - mostly for my own usage and to explore stuff. I’ve made a lot of mistakes along the way and here are some of the things I’ve learnt. Most of them might seem like common sense in hindsight, but…such has been my path.
If I started building something, this is what I’d do:
Deciding what to build
Depends on your aim. My aim was to do something I’d use and learn some tech in the process, so my criteria generally is:
- Something that makes my life easier
- Something I’d use consistently
Why did I pick that criteria?
Most deep understanding comes not when we build the initial version, but when we start adding new features or stray off the “happy path”.
Eg: Learning React or NodeJS or Mickey as a beginner can be pretty simple. We have instructions to set it up, a nice guide of SelectQueries and DataObjects and things to do - the happy path.
But when we start needing complex operations down the line, we deviate from the “happy path” and try to figure out how to achieve our use-cases with their abstractions; this is when we really start to understand and appreciate the many technical capabilities and decisions of the technologies.
So once you build your app, you need consistent users to get feedback, iterate and improve it. It’s hard to get users - a problem faced by pretty much any company. (Except Zoho, where if you want to get feedback or load test anything, you can host a townhall and instantly get 10k users and feedback. :P)
Often you end up being the only user of your app - and you’ll use it only if it makes your life easier, which is fine by me.
If your aim is to get other people to really use your app, your criteria will involve more market research. You can do things like:
- Search social media for specific things in apps people complain about
- Look for top-grossing apps with a low rating, maybe you can research and do it better
A few examples of dumb things that I used consistently:
- NarutoLauncher
- AutoShutdown
What should your app do?
- Think of what features your app should have
- Look at other similar apps for inspiration. At least look at their landing pages and screenshots (remember to save all these screenshots!)
- Try to write down why you want those features, how often you’ll use it, when you’ll use it and what value it provides
This is mostly because you shouldn’t come back after a month and forget why you’re even doing this. Putting all this in words might also force you to think about your assumptions.
“my knitting guide app NEEDS to have 5 color themes!”
“why?”
“well because any good app has it”
“in any app with 10 themes, have you really used anything other than dark mode?”
“…”
Now categorize all the features you wrote down, maybe as two levels of headings.
You da MVP, but even you need an MVP
MVP - minimum viable product is a product with the least amount of features that you could actually use.
Make a UI
Always do this before starting any sort of your implementation!
This is one of the most important parts of the process.
- Without a UI, you don’t know what data the client needs
- If you don’t know what data the client needs, you don’t know what needs to be processed and sent by the server
- If you don’t know what data needs to be processed and sent by the server, you can’t do data modelling or pick a DB
Considering how nammale kashta pattu irukra gap la panrom, it sucks to have to throw code away.
Apart from the extra time it takes, it can be very demotivating and you start considering abandoning it and moving on to a different app.
But I don’t know UI design!
You don’t have to. I’ve graduated from pen and paper to MS Paint to Canva (which I currently use).
You know generally what components you want - make a rough mockup. Copy structure from popular apps or Dribble, copy color schemes from color palette websites.
Picking tech
We might have different layers for the app. Generally they’re: frontend (UI), backend (processing), DB (store data).
Apart from this there are choices for APIs (REST? why not GraphQL?), languages etc.
My suggestion is to ideally pick one technology you aren’t familiar with. If you pick too many unknown technologies, you end up with kind of a fatigue - exciting initially, but you end up spending a lot of time trying to figure out the basics or best-practices and fixing bugs without knowing where to start.
If you intend to finish your app, pick the least number of new technologies you can.
Add todos
You know what features you need to build and you have your UI screens. So split your MVP features into bite-sized todos.
If you have 10 minutes, you want to be able to open your IDE and jump right into building it. You shouldn’t be spending time thinking about or deciding what to do next.
Thinking of what to do next is for when you’re in the shower or taking a walk or watching TV :P
Implementation - business logic
Pick a UI, see what data is needed from the server. If you’re using a familiar backend tech, no issues.
If not - build a basic backend with a helloWorld API just to see what kind of requests it accepts and what kind of responses it’s capable of sending.
Once you do that, you have an idea of what APIs you can build with your shiny new backend.
Now skip to the frontend. See what info is needed to render your UI, hardcode it and build your frontend. Now think of what data is needed from the server to arrive at this info - hardcode it too! Work on transforming your hardcoded backend response into your hardcoded frontend info.
The most important part of your application is your business logic. No user (even you after 2 weeks of using it!) will care if it runs on a graphDB or Clojure or Reactv24 or a super computer. So focus on that!