With returns tracker, I set out to help a friend's e-commerce business automate their return order refunds. I thought I could build a small, but useful tool, and that if my one customer was happy, I could sell it to other e-commerce companies as well.
I didn't have the coding skills, but I thought I understood the payments domain well enough to be able to pick up the coding skills I needed, and build something useful.
I've really enjoyed learning to work with React and Python. Perhaps too much, as I could have used that time to work with my client to design a full solution, and do a bit of customer discovery to validate the problem I was tackling.
In the last few weeks, I've focused my time on customer discovery. I've had the pleasure to talk to a range of very smart people about return payments, and payments more generally.
Turns out, this project isn't going to succeed. Below, I explain where I went wrong.
Returns tracker is essentially a process automation tool. When automating processes, you are doing one of two things:
The first approach will result in a product. The second approach will result in a consulting business.
Without realising it, I was going down the second path. Since my aim was to build a product, that's not good.
Here's how I failed:
To reinvent a process you need to have deep domain knowledge. I found myself out of my depth in the e-commerce order management space.
I would solve one problem, only to find out from my client that there are three more steps in the process I wasn't aware of. This happened several times.
As of now, I've got a list of seven separate APIs I need to connect with to automate the returns process:
I also discovered that my client's plans to replace card refunds with bank transfers would expose them to chargeback risks. Cutting out card payments from the process meant reducing the number of returns payments I could automate significantly.
In addition to API integrations, I needed to build:
At this point, I realised it was clearly going to be a custom build just for them. Is doing a custom solution such a bad thing? It depends on the size of the problem.
Unfortunately, I knew from the start based on some the number of return orders they process that the amount of time I could save for my client wouldn't be enough to make this a viable project stand alone project. While building it out has been fun, committing to maintaining all those integration (with no upside, as it would be a one-off integration) wasn't something I would enjoy.
So, I am now going "Indie Hackers Official" with closing down.
it's been fun, and I've really enjoyed the support the Indie Hackers community has provided. I've gotten to meet some fantastic people here.
I've salvaged the useful bits of the work, which is an NPM package for collecting bank account details, and a back office tool for integrating to TransferWise and other payment providers.
Perhaps the most fun bit was when someone on Twitter decided to contribute additional language support to the NPM package. The Internet is truly awesome for collaboration.
Here are the stats on the Bankdeets.co NPM package I published:
Even more fun, I've got a few people interested in using this in production. That's pretty exciting, and if it becomes a reality, I will consider this project a success.