I was super excited to work on building (Loominex)[], a maintenance management system. Today, after 8 months of effort, I’ve decided to shut down Loominex. It was a great learning experience that I wish had ended differently; however, I’d like to share some of the things I learned.

Try to Get Payment During the Product Discovery Phase

I remember reading Inspired by Martin Cagan, where he mentions the need to answer four simple questions before writing a single line of code:

• “Will the user buy this (or choose to use it)?”
• “Can the user figure out how to use this?”
• “Can our engineers build this?”
• “Can our stakeholders support this?”

With this in mind, and having spent too much time in previous projects building only to realize no one wanted what I had created, I decided to follow this advice and try to answer these questions before building.

I created a form in Airtable to first validate if there was any interest in building a new maintenance management system. In the form, I asked for personal information and questions about users’ pain points. I shared the form in maintenance management online communities and was surprised to receive over 27 submissions.

I thought if these were real people, they would be open to jumping on a call, so my cofounder and I decided to schedule video chats to learn more. During these conversations, potential users expressed the need for a leaner maintenance management system, issues with complex UIs, and many more pain points they struggled with.

I was surprised by the engagement, so we set out to build our MVP. With excitement, we released our MVP, onboarded many users, only to realize that only one user converted after the 30-day free trial.

Lesson: Get payment upfront before you spend months building your idea.

Decrease the Number of Features

When I launched Loominex, I thought we had a good balance of features. Our MVP included Inventory, Equipment, Dashboard, Ticket Assignment, and many more. For our onboarded users, I had a Slack space to maintain a direct line of communication.

I came to realize that some of the features users asked for during our discovery phase weren’t being used. This was time that could have been spent differently to help the success of the startup.

Looking back, if I had decreased the number of features, I could have saved a couple of months of development. I would have had more time to talk to users and improve their experience using the app.

It Takes Money to Make Money

Storage is historically cheap, and you can set up a good infrastructure for less than $100 a month. However, as your startup grows, costs start to creep up. People begin uploading a lot of images to S3, you realize you need database backups, and you need to update your hosting service plan.

Also, you might need to spend a few dollars on marketing to reach potential early users. You don’t need to worry about scaling in the early days, but you do need to have a stable application that works well.

Lesson: If you’re going to start, make sure you have a few months of runway.

Conclusion

Building a startup is extremely hard and devastating if it doesn’t work out. The hardest part is letting go of something you put your heart and soul into. However, with these tips, I hope you’ll be in a much better place when building your project. I’ll surely be back to do it again. Good luck!