Ognjen Regoje bio photo

MY NAME IS
Ognjen Regoje
BUT YOU CAN CALL ME OGGY


I make things that run on the web (mostly).
More /ABOUT me.

me@ognjen.io Twitter LinkedIn Github

Shit you can get away with when you're in a dominant market position

Below are actual examples of issues I had with a provider that is in a dominant market position. I have to be vague and cannot name names because I still work with companies that rely on them, but they provide a crucial service. They have no competitors that offer a comparable service. Furthermore, given their niche, it is exceedingly difficult to even start competing.

Because they have been the incumbent for so long, and because it’s so difficult to get started in their field, their moat is so wide and deep that Moses himself couldn’t get through. So, they have long stopped giving any fucks.

If you find yourself in a similar situation, here’s shit that you can get away with.

Your API can be wildly inconsistent

You can have all endpoints use different hashing algos: one can SHA1, another MD5, and a third SHA256.

You can require base64 for one endpoint but not for another. One can return in base64 but not the other.

Sometimes you can delimit fields, sometimes not.

You can run one on one domain and another on a different one.

One will URLEncode, and another won’t.

You can, of course, mix CamelCase and underscore_case and Whatever_Thisis.

You can have awful docs

First of all, you don’t need to document everything. Your customers can figure things out themselves.

You don’t have to make the docs public. You can have your customers email you for them.

You don’t have to make them thorough or complete. You can wait for customers to ask for clarifications.

You don’t have to care about grammar or spelling. You can let your customers decipher what you mean.

You don’t have to put them all in one place. You can describe each piece of functionality in a separate document in a different style maintained by a different person.

You can put code samples in the PDF itself. And don’t worry, they don’t have to work, they’re just samples after all.

Your support can blame your customers

Before you do any debugging or checking, make sure to blame your customers. They must not have deciphered your docs properly.

Then, when you do, make sure to do the bare minimum while again blaming your customers.

Eventually, they will give up and make customizations to cater to your particular way of doing things. Don’t worry, they will.

You don’t have to be accurate

Each one of your support staff can tell your customers different information. One story is bound to be correct.

If a customer asks you about something in their account, don’t worry, you don’t have to actually check it. Just assume.

You can be technically stagnant

There is no need for you to improve in any way.

You do not need to support any new features that other providers in your field support.

You do not have to update your design since 1998. It’s timeless.

Actually, you don’t need to be technically competent

You can send live emails for test transactions.

You can run things in the main thread that should be in background processing.

You can then crash the main thread if the background processing fails.

You don’t need a test environment. You can create dummy accounts in prod.

You can charge setup fees for everything

Imagine you created a Stripe account and wanted to accept credit card payments. But your account could only accept UnionPay. You get in touch with Stripe support to enable Visa, Mastercard and Amex. And Stripe support replies, “OK, sure, here are three invoices for the setup fees for each of those”. You can do that.

That’s why competition is good (or bad depending on who you ask)

If they had a competitor pushing them, threatening to take their customers, they would solve most of these issues overnight. But they don’t, so they don’t. And if you find yourself in this position, you won’t either!

#competition #product