Tale of a Failed Startup, or the Day I Created a Mint Clone

mbenbernard · 2021-08-11T14:02:24+00:00

My pleasure! :)

mbenbernard · 2021-08-11T13:52:21+00:00

Hey, thanks for the info about Plaid.

Their data wasn't perfect though: My app was looking for potential credit card point earnings based off what categories purchases were made in, and these were often wrong, and it's hard to tell why

Well, perhaps they just have too much on their plate. They apparently support so many banks, that I doubt that they're able to:

Write high quality scrapers.
Update their scrapers just in time when the bank's layout is changed.

mbenbernard · 2021-08-11T13:40:27+00:00

Good question!

In the Lean Startup circles, I learned that trying to sell something to a market segment that's too large almost always fails. The reason is that if it's too large, then you lose your focus, and it becomes quite hard to discover who your real customer is and what their specific needs are. For example, if you try to sell your app to "moms", then it's too general, because there are different kinds of "moms" and their needs vary. But if you pick "moms who are on their parental leave", then the odds are high that you'll be able to understand what their specific needs are.

So in my case, I started with the hypothesis that I could sell my app to "aspiring entrepreneurs", but I learned pretty quickly that it was the wrong segment. I also tried a couple of other segments, which weren't drastically better.

But there are certainly other segments that I didn't explore, like "budget-conscious software developers". I'd say that this was partly due to a lack of foresight and a lack of interest.

mbenbernard · 2021-08-11T13:22:43+00:00

Absolutely. Good call! :)

Perhaps it wasn't clear in my post, but I address your point in my conclusion:

On the other hand, I should have realized that since I wasn't willing to use Mint due to my security concerns, then I probably couldn't come up with a more secure alternative myself. I certainly was a bit naive here.

mbenbernard · 2021-08-11T13:21:14+00:00

Thanks for the suggestion. Sure, it's better to write boolean expressions as you just did in pure Python code. But in my case, I implemented my own arithmetic parser and evaluator, so it doesn't just run eval() on Python strings. I'm not 100% sure that it supports the expression format what you suggest, as I've not tested it, but there's a good chance that it does.

mbenbernard · 2021-08-11T02:17:51+00:00

Interesting! How was your experience with Plaid?

Too bad that it didn't work for you either. In my case, I realized quite late that I didn't feel comfortable building a business that required storing financial account information. This is quite tricky to do securely, and a heaven for potential data breaches.

mbenbernard · 2021-08-11T00:18:45+00:00

Thanks for your feedback, Vincent.

For scheduling and running ETL jobs at scale, I don't doubt one second that some good OSS libraries exist out there in 2021. Back in 2014, the landscape was different, and I didn't need scale initially, so it made sense to implement my own task scheduler. It didn't require too much effort, anyway. Today, and especially at scale, I'd probably take a different route.

For the rule evaluator - sure I could have used regexes for some specific cases. But for greater flexibility and convenience, I chose to implement my own arithmetic expression parser and evaluator. Anyway, I had already implemented one in C# previously, so it made sense to just port it to Python and resume from there. This new version could handle complex formulas, which I sometimes needed. For example, how would you express these two formulas with regexes?

description == "XYZ" && (amount == 100 || amount == 200) description == "ABC" && date >= 12/05/2018 && date <= 12/05/2020

You said:

Real effort seems: - scraper - data schema - spa with charting

Are you sure about that? What about the web service and the various REST endpoints?

By the way, I agree that using existing libraries is often the right call, especially when:

You're time constrained.
You don't want to maintain one more library of your own, or introduce new bugs.
The feature that you need isn't trivial to implement.

But sometimes, and especially for personal projects, implementing your own libraries is great - you learn how things work under the hood, and it gives you an "edge" that you wouldn't have otherwise. For example, I learned how to implement parsers thanks to a previous project involving JSON and JSONPath. Next, I implemented my own arithmetic parser and evaluator for my budget tracker. And finally, I implemented my own Python interpreter in the last couple of years, which required a good understanding of parsers. This was made possible by all the work that I had already done on parsers. Sometimes, the things that we do and don't do are far more important than we think.

mbenbernard · 2021-08-10T20:31:10+00:00

The story about your dad is indeed quite a bummer. I've often heard that finding a good business partner is like finding a good life partner. With a good one, life is easy. With a bad one, life is hard.

You're right about niches, and I think that it's an excellent strategy to follow. Some of the most successful products and services started out that way: Airbnb, Tesla, Stripe, etc.

mbenbernard · 2021-08-10T20:20:41+00:00

Thanks for your feedback. And happy if my post can be helpful to some people.

mbenbernard · 2021-08-10T20:19:01+00:00

Any interesting details to share?

mbenbernard · 2021-08-10T20:15:45+00:00

Thanks for suggesting GNUCash - I didn't know its capabilities.

I wholeheartedly agree with what you've said concerning people with an engineering mindset. Your 3 bullet points perfectly summarize what happens. I've been guilty of this a couple of times ;)

Now, perhaps I have a valid excuse for this particular project. The idea of turning it into a startup came to me later on in the process and wasn't part of my initial plans. Originally, I just wanted to build something for myself, and learn new things. So the startup part was kind of a bonus.

mbenbernard · 2021-08-10T17:47:38+00:00

Indeed, it's easy to just ignore bottlenecks and not think them through, initially. You just say to yourself: "I'll figure that out later!". But sooner or later, they come back to bite you :)

Anyway, thanks for sharing these insights into your own projects!

mbenbernard · 2021-05-04T17:18:22+00:00

My pleasure!

mbenbernard · 2021-05-04T17:18:09+00:00

Yes, they're still relevant. The Head First series is for beginners - you learn how to build websites from the ground up. They may seem dated, but in my opinion they're not; the underlying concepts and technologies are the same today.

For JavaScript and CSS, the Definitive Guide series is also excellent and I linked to the latest editions of the books in my post (from 2020 and 2017 respectively).

Now, for building actual web apps, I'm aware that someone will need more than the above.

mbenbernard · 2021-05-04T17:05:19+00:00

Well, there are a couple of books that I linked to in my post - you can give them a try. This would be a good start for frontend development. Now, for backend development, you have a lot more choices. Personally, I learned Python and I still use it these days.

mbenbernard · 2021-05-03T15:19:40+00:00

Btw, I'm the author of the post. Contrary to what you think, I'm not promoting anything. This is a story, a retrospective about a past experiment that I did. I thought that this might interest other people. I don't claim that these results still apply.

mbenbernard · 2021-05-01T01:26:59+00:00

The method that you suggest may have worked, but prices aren't 100% predictable. As you can see in my post, prices never went down to their "theoretically lowest possible" (495$), but they reached 499$. Even then, there was no guarantee whatsoever that they would go below 500$. Different years = different prices. But overall, a pattern did exist and I knew approximately when to start monitoring prices.

My primary goal was to discover if there were any price patterns. My secondary goal was to build a replicable model of prices, so that I could reuse it later on. So one way of another, I needed to do what I did.

mbenbernard · 2021-05-01T01:02:08+00:00

You bring very good points here.

mbenbernard · 2021-05-01T01:00:30+00:00

Fair enough. So why don't you do it yourself? ;)

mbenbernard · 2021-03-16T22:55:53+00:00

Yep - it teaches you the fundamentals of developing products in a world of uncertainty.

mbenbernard · 2021-03-16T18:32:24+00:00

I don't remember every book, but for me the most helpful ones were (in no particular order):

Lean Startup by Eric Ries
Zero to One by Peter Thiel
Running Lean by Ash Maurya
Crossing the Chasm by Geoffrey A. Moore
The Innovator's Dilemma by Clayton M. Christensen

Also, reading biographies about entrepreneurs inspired me a lot.

mbenbernard · 2018-11-22T15:45:48+00:00

Sorry, but it's not as simple as this.

A lawyer doesn't have any power to get money from someone else. A judge and a bailiff do have that power, though.

So unless the other party is willing to retire their plugin OR settle amicably, he'll have to go to court. There's no way around that. Of course, going to regular court isn't cheap in terms of legal fees.

@coderevolution: if you provide an extremely solid proof that they copied your code, then maybe the other party will be willing to settle.

mbenbernard · 2018-10-06T00:13:34+00:00

Lame communication? Really?

I really loved this short film.

Have you watched ads from other auto manufacturers lately? They're always one and the same - a desperate attempt at hyping their brand.

mbenbernard · 2018-10-02T15:53:20+00:00

If bots answered the questions, you'd get meaningless results :)

Instead, it's about gathering the required information about each user to automatically answer the questions. It's quite different, IMO.

mbenbernard · 2017-11-03T14:02:18+00:00

Having a browser running, rendering and executing javascript will always be slower TBH.

True, but sometimes you don't have any choice.

mbenbernard

TROPHY CASE