Hello to my first Indie dev log! I've realised that documenting my journey could provide valuable insights for others starting out on their own paths.
I'll begin with some facts about myself.
Started working as a software engineer in 2015, when AngularJS was becoming obsolete in favor of Angular 2 and we were excited for upcoming ES6.
From this time I worked on something about 30 projects mainly focused on "in-house enterprise apps", related to outdoor and online advertisements, finances but also for government websites like homepage of Polish Ministry of Health
What all those projects have in common is that I can't show you any of it because of NDAs <3
So my portfolio after 8 years of wrestling with code contains nothing, null.
Since last year I'm mainly focused on my own projects, under my own name, no strings attached.
Let's talk about independent projects
One observation I've made is that when you change jobs or get fired, you lose everything related to that job. You can't showcase any work from it; you're left only with your knowledge, which anyone can obtain.
That's why I'm currently laser-focused on my side projects.
This doesn't mean I've become less productive at my job; in fact, I've become even more effective by having space outside of work to experiment, engage in fruitful discussions with other developers, and try new frameworks, tools, and ideas.
It's a shift of focus. Your job should be treated like the Olympics, where you show the best of you. You got paid for delivering a working solution in the shortest time possible and code should be maintainable for next 5 years at least. It's not a place for experimenting or delays because "I tried something new and it didn't work out".
However, your Indie App is like a "greenfield project." As the definition suggests, it's an independent application where you're the boss, the tech lead, and the product owner all in one. This freedom allows you to explore ideas that would require permission in a traditional job setting.
Sticking with the nomenclature of the Olympics, Indie App is a your training base, it can be rough, at the beginning it can lack of testing, good practices, have a lot of repeatable code. It doesn't matter for end user - if you solve its problem, then you're getting paid.
That's why it's a great idea to shift your focus to your own projects, this is where developer actually should loose some hair, shed a tear and sweat. Job is a place for "formalised code", where you strictly keep to the rules and eventually show your new ideas from your side projects (and I can tell you from my own experience that you'll get a lot of them when you start even some trivial projects).
After some time you'll get much more experience as a developer and your day-to-day job became almost tireless, you'll just repeat what you did few weeks ago in your own project.
Beside of that you'll also gain more experience related to marketing and cost-to-profit ratio when it comes to project. That could potentially lift you up in job hierarchy.
And that's why I started my new journey.
SnapCity - Automatic travel planner
This week I focused on another pack of new features but also on keywords.
ASO and Keywords
Application Search Optimization (ASO) was a new concept for me, but it boils down to:
Find what keywords your competitors use (in my application it was for example "Travel", "City", "Walking trips" etc).
Use them in the name of the app, subtitle and keywords field (on Apple App Store the description is not taken into consideration by search engine)
And that's it! Sometimes you can experiment with different screenshots, different icons, test what pack of keywords "works", but keep in mind that it takes a lot of time (you need to be first indexed by search engine and gain some data).
Remember - this is your first funnel of getting customers. That's why I'll try to focus on this for next month and see how it'll work out.
My currents stats looks like this:
Those stats are from 01.01.2024 to 11.02.2024.
At the time of publication of SnapCity I didn't know anything about keywords and just used what came to my mind. And as I said - I'll change them in upcoming update and post my results in upcoming Retro.
Some tips regarding keywords
- Title of app should be meaningful
My previous title was "SnapCity AI", as a user I would think "what the hell is SnapCity" and "another shitty AI app". Now I've changed that to "SnapCity: Travel planner" - now it gives some information and contains two keywords - "Travel" and "Planner"
- Use your subtitle wisely
It also can contain a lot of keywords, in previous version I set "Generate trip plan in seconds", maybe it gives some information for user, but it's not what he typed in search form. Changed that to "Plan your next city trip" - as you see, those are words which user could potentially type to search form - "city trip", "plan".
- Conduct A-B tests.
For few weeks stick with one set of keywords and screenshots and the next one try different one's. There's no one recipe for success.
Possibility of archiving the plan
Maybe that's not a crucial functionality right now, but it was low hanging fruit which I could fix in my spare-time.
But the way of adding this functionality required some dose of creativity. When you want to Archive something you
Need to distinguish archived elements from not archived
You can't remove it right now, but after some time (to keep the base clean)
You need to add possibility to restore that element
Also there should be option to remove permanently
So how do I achieved that?
Database
Created a additional column in Supabase - "archived" with boolean value.
Added a cron job every week that will remove all trips which have archived status "True" and last update was more or equal last 7 days.
API
- There wasn't a lot work to do because I already had "PATCH" method for Trips. I just need to send "archived: true/false" to certain ID. But I had to add "DELETE" method for permanent delete option.
Application
Added a new buttons - Archive, Restore and Delete permanently which.
The list of Trips always download all trips, archived and not, so I decided to just filter archived one's out on the Front-end side (maybe I'll change that latter to request not archived ones first from the backend, to reduce data usage).
Also I had to add a new "Archived" screen, where user can restore and delete permanently trips, but that was just recycled Trips list.
Improved plan calculation time
This one is funny one, because I've decided that I can write trip planning mechanism on my own, without usage of OpenAI. Thanks to that I've reduced calculation time from 30 seconds to... 100ms. Sometimes it's good to think twice about usage of "AI"...
Thanks for reading and see you next week! 👋