My partner and I at CyberHut are thrilled to be launching our very first application called NeatPick! We’ve chosen PostgreSQL as our DBMS, Flutter on the frontend and NestJS on the backend thanks to our positive experiences with this stack.
NeatPick
NeatPick used to be a side project with no limits and boundaries, and its goal was to decompress from the fast-paced environment and leave the toxic Ionic framework behind with its random errors and unsupported packages.
At one point, we realized that NeatPick has potential and we decided to make it our first in-house project. I can compare it to a web shop: people will search on a mobile app, browse through pages of products and view details about an item they are interested in. Eventually they will stumble upon something they like enough to start the process to purchase the item. Sometimes they will apply updates to their own profiles or check out other people’s profiles to learn more about the seller or the buyer.
Mistake 1: Fixing everything before release
Developing your own product can be tricky. You are never 100% happy, you want to fix those bugs that bug only you before release, you think that there should be more premium features, that the competition is still better, and the users you lose in the early days due to these reasons will never come back. The media is also saying that compared to Millennials, Gen Z is unforgiving but you want Gen Z to be your customer too! How much damage will a bad review cause? I need to fix this, and I need to add that to make the app perfect! Or not…
Mistake 2: Adding more features before release
I am a person with way too many ideas. Every now and then I get an idea for a new app or feature I would like to add to NeatPick. Sometimes I leave it as a task to be discussed on Trello, while other times I just need to get it out of my system by creating the frontend and let it sit on a branch.
My partner reacts to this quite well: he engages in the discussion about my new idea, explains his view, we speak about how we could solve it and how we could integrate it into our system. We discuss potential drawbacks and benefits and sometimes a new task is born but we agree on one thing: we need to focus on what we have in front of us, what we planned to release and those features need to be buttoned up before moving forward.
If we introduced a new feature, it might add some complexity when doing it in a hurry. It would almost always result with new potential bugs.
When clients are too excited
There are many prioritization techniques, and we picked ours a long time ago, when one of our non-technical clients’ representative kept arriving to each meeting with a larger scope of the project. They did this for every meeting. First, we were a bit annoyed. We re-calculated our estimates and then once again, they appeared with an updated set of functional requirements, with more side-details that happened to be new features. It was very frustrating. They were not ill-minded, they just got too excited about the product and its features and they did not know they were causing us trouble.
Lesson: always charge for calculating estimates, even when you are desperate. Clients will take your numbers to others anyways.
To the next meeting, we arrived with something super simple and super useful: the MoSCoW method.
MoSCoW method
The MoSCoW method is a four-step prioritization technique used in project management. It helps prioritize project requirements in order to achieve the best return on investment (ROI).
Regardless if this is your project or not, you can greatly benefit from MoSCoW. It is very easy to understand and remember, and it quickly allows you to isolate the requirements you need to prioritize.
The four categories you can divide the requirements are Must Have, Should have, Could have, Will not have.
Must have: critical core requirements the app cannot function without.
Example in NeatPick: authentication, authorization, submitting a game for trade, search settings and browsing through a list of games
Should have: important but non-critical requirements
Example in NeatPick: allowing users to interact with each other, agree on meeting location and time, offering a combination of money and game for trading a single game
Could have: optional requirements that can enhance the project and would be nice to have (clients say: if there is time/money, we will …)
Example in NeatPick: advanced analytics for our premium users
Will not have: requirements not included in the current project scope
Example in NeatPick: push notifications
Final Thoughts
I still rely on this method today because it gives a straightforward system for both non-technical and technical clients. It helped us isolate critical tasks when everything was presented as an urgent. It helped our clients communicate much more clearly.
If the most critical requirements are always addressed first, you can expect a potentially successful project outcome and meet or even exceed the client expectations. Or your own.
