[^<]+|<(!(--([^-]-([^-][^-]-)->?)?|\[CDATA\[([^]]]([^]]+])]+([^]>][^]]]([^]]+])]+)>)?|DOCTYPE([ \n\t\r]+([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])([ \n\t\r]+(([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])|"[^"]"|'[^']'))([ \n\t\r]+)?(\[(<(!(--[^-]-([^-][^-]-)->|[^-]([^]"'><]+|"[^"]"|'[^']')>)|\?([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])(\?>|[\n\r\t ][^?]\?+([^>?][^?]\?+)>))|%([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F]);|[ \n\t\r]+)]([ \n\t\r]+)?)?>?)?)?|\?(([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])(\?>|[\n\r\t ][^?]\?+([^>?][^?]\?+)>)?)?|/(([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])([ \n\t\r]+)?>?)?|(([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])([ \n\t\r]+([A-Za-z_:]|[^\x00-\x7F])([A-Za-z0-9_:.-]|[^\x00-\x7F])([ \n\t\r]+)?=([ \n\t\r]+)?("[^<"]"|'[^<']'))*([ \n\t\r]+)?/?>?)?)
1. You could sell tutorials and ebooks on regexes. People who use your tool might want to understand why their regexes are not working.
2. You could license your debugging code/technology.
3. You could sell a corporate license to use your site. Corps’s regexes won't be shared publicly. Others might be. Corps paranoid about people stealing their regexes might be interested in your product.
4. You could ask for donations to support the site.
5. You could make it social. Have people vote on regexes. Have another complementary site where people contribute test-cases for common regexes like phone numbers, dates, email addresses. You could hold competitions in different categories.
6. You could offer a cloud-based regex parser. I know it sounds a bit absurd, but I want to throw this out there in case it leads to other neat ideas.
7. You could save regexes and have people vote them up. You could have discussion threads around regexes.
If you learn nothing else from Wikipedia, learn this: Begging annoys users and isn't particularly successful. He is far more likely to make money selling a premium subscription to corporate users. He can even just say "site is free for personal use, and corporate users must pay $495/year". You would be surprised at how many businesses are paranoid enough about compliance that they will voluntarily pay even if it is unlikely that the site owner would ever find out about their unauthorized corporate use.
As far as I know, Wikipedia fundraising efforts have been very successful. They got $25 million dollars just last year.
But yes, I agree, it seems possible for WP to accept advertisement without compromising on its core values. Decide in advance never to give in to such demands, and do not take the funding for granted.
Deciding not to accept advertising might be short-sighted. With enough years of advertising revenue, Wikipedia might be able to work toward financial independence (where returns on investment exceed costs), and build an endowment like the sort that powers top universities.
Also, I don't have to watch any ads! Hurray for Wikipedia!
Even if Wikipedia used the most unobtrusive, low-key advertising system possible, people would still react negatively because Wikipedia is known for having no advertising whatsoever.
maybe? but compare wikipedia's uptime to, say, twitter or reddit. Advertising dollars do not always make for reasonable Engineering decisions. (I'm not saying that advertising causes twitter or reddit to go down often; but they both get dramatically more revenue per user. I mean, dramatically more revenue per user, and they both have terrible uptime vs. wikipedia.)
 Jimmy Walles on Quora: http://qr.ae/TL1ku
Rationale: Almost everywhere in the world outside of US and Canada, phone numbers do not look like that, and interacting with websites that assume they do is frustrating. Even USians or Canadians may want to enter a phone number with an extension, which would get rejected by that regular expression (a colleague of mine got frustrated to no end by websites and bureaucracy assuming the 3-3-4 style of phone numbers when she moved to Canada, because she prefers not to use a cell phone too much, and her work number has an extension).
The logic of the points that are being made is flawed, starting with repeatedly conflating building a product for a small market with solving a small and simple problem. These are not the same.
In general, solving problems for small markets is just as hard as solving problems for big ones.
My advice is, at the level that you understand what to build to get to market, go after the biggest fastest growing markets you can.
I think you misunderstood my argument. That may have been entirely my fault; I'm still learning to write.
Small and simple problems are rare in large markets because everybody is chasing after them. The low-hanging fruit get picked very quickly, and you need to produce more to reach the bleeding edge.
By contrast, smaller markets have more low-hanging fruit simply because there are not as many people picking them.
Certainly not compared to what is possible...
I think I understood your argument, I just disagree with what you are asserting and your conclusion.
There is plenty of low-hanging fruit in big markets, because it is a proportionally bigger tree.
If you add the constraint that you want to do everything on your own, then the markets and problems you can reasonably approach are smaller, but I still argue that from a return on investment perspective, you should be looking for the largest market opportunity that you understand enough to build.
If you care to discuss in person, I'm on twitter with the same name. @ me and we figure out the best way to facilitate a discussion.
Surely that can't be right.
The very nature of a small market, implies that the solutions are easier - because of less competition, so less innovation is needed, therefore lower return.
With larger markets, not only do you have to solve a problem - you have to solve a problem better/different than your competitors.
Not all solutions are created equally and not all solutions solve the problem in the way the customer wants.
It's harder to separate the signal from the noise when the customer doesn't know what the solution should look like - and when the competitors don't know either.
Quite often, in a large market, many competitors exist largely because no 'significantly better' alternative exists. Think about all the crappy desktop software (from the 90s or early 2000s) that many small businesses still use.
In a smaller market, you are more likely able to get away with simpler solutions - e.g. a CRUD web app, versus having to come up with a more sophisticated solution because competitors have already squeezed as much out of CRUD apps as they can.
Competition and the size of the market are not always correlated.
The superior strategy is to maximize returns against efforts, not minimize potential for competition.
The essential argument is that a small market provides small returns therefore go after small markets is not the same as proving that the returns are better in proportion to the cost, in time, resources or opportunity.
Most large markets are divided in following a Pareto distribution, which is to say the winners dominate. You don't have a pie divided between competitors, you have most of the pie going to 2-3 players. Be a player.
When you see a large number of 'competitors' in a market, as often as not the market fragmentation is on the buyer side.
Again, I don't buy the small market simplicity argument, and I especially don't buy that small markets offer the best returns for effort. There is an abundance of large markets, many of which are underserved.
If you see an opportunity to squeeze a little market with a CRUD app, by all means, don't let me stop you, but I don't believe that is a superior strategy.
I wasn't making the argument that small markets offer the best returns for effort. Clearly that can't be true either - just by its definition.
The notion that there are an abundance of large markets, many of which are underserved is quite a simplistic argument.
There must be a reason that they are both a) large, and b) underserved.....probably because the barriers to entry are exceedingly high. Energy markets come to mind. Hard to get larger markets than that, but it is easy to find large subsets of customers that are disgruntled and would gladly switch to a `better service`.
The trick is that every Tom, Dick and Harry can't start an energy company. It is VERY capital intensive, even more labor intensive and heavily regulated.
So, I think if you were to reword that statement to say:
"There is an abundance of large markets, many of which are underserved...and easy to reach/service for a single web developer anywhere in the world". I would surely argue that to be false.
Energy, computer hardware, medical, pharmaceutical, telcom, these are big markets with big stakes, and these are difficult to enter, even for well funded endeavors.
That being said, the internet is still relatively young and acts as a force multiplier enabling anyone to have far greater reach than they could have even 20 years ago.
Relative market size has remained largely undefined to this point. I think the obvious definition of market is in terms of dollars.
What do you consider a large market? A million dollars? tens of millions? 100s of millions?
We should also define abundance.
In 2011, the US GNP was 15,097,083 million USD. If we just say 1% of that is potentially addressable with a technical solution involving the web, that is still over 100 billion in play just in the US.
I don't know about anyone else, but that seems like abundance.
And that's just in the US.
In 2013, as a web developer anywhere in the world, you have never been in a better position to leverage the global economy.
That feels like an abundance.
Perhaps it just comes down to axiomatic world view. Do you see abundance or scarcity?
Again, I say people should go after the biggest market they feel they have a fighting chance to penetrate. Go big, because you can. Fortune favors the bold.
That should be 15 trillion (definitely not ~15,000,000,000,000 :p )
I can't tell if you are being sarcastic.
15 trillion, in it's secret double life, looks suspiciously like 15,000,000,000,000.
A single programmer writing CRUD apps isn't going to become a competitive telco. I'm not saying wade into fights you can't win,just that if you have to decide between two projects, a considerably larger market should be key to the decision.
Thanks for the book recommendation.
Any other reason you think this person has no understanding of markets? Because so far you've got nothing.
I also believe you are too focused on 'minimal' at the expense of 'viable' in MVP.
If you have relatively a relatively viable product, where would you rather sell? I'll take a big market every time.
If the point is what you say, then why does the original post repeatedly return to the theme of the simplicity of the solution?
I say the person has no understanding of markets because no point being made in the original post is actually about markets, or products for that matter. There is just a list of assertions and assumptions to justify choices that were already made.
If you want to build products for small markets, by all means, go to it.
In another response you say you don't think you were particularly aggressive. I think you need to evaluate how you present your arguments because you have, twice now, used unnecessary ad hominems.
You've reversed his entire story. He's saying "I built this simple thing and because it's in a small market with no entrenched gorilla's, I'm getting traction, you can too." It's an anecdote, not data, I agree, it does go towards establishing the point he is trying to make.
Nor is being disagreeable for that matter...
I was dismissive and probably impolite. I apologized.
You didn't answer my question, so I'll ask it again, what makes you believe that an MVP will be more salable in a small market?
You say 'regardless of the complexity of the MVP', but that invalidates every point the author was trying to make. Point 1, 2 and 3 in the original article all hinge on the level of effort of the MVP.
Where you worked is not something that changes anything about your position.
I reversed nothing. The author asserts some things that are provably false, then asks 'What are your thoughts? Should your first product be aimed at a small market?'
There is traction because something was built that solves a problem. The size of the market and entrenchment of the incumbents are not the same thing. This person can do everything because the problem and solution are small enough to allow that, not because of the size of the market. Further, attributing causal relationships to the size of the market and the traction is a mistake that leads to sub-optimal strategies.
Those are my thoughts. Do what you will.
Not all niche markets are small in terms of revenue/cost either: there are product niches worth millions (or even billions) whose actual feasible customer set barely makes it into double digits. But when the niche is that small in terms of customers you find that despite the lack of threat from competitors it's actually the customer that owns the niche....
My app is the absolute niche of niche ( https://play.google.com/store/apps/details?id=com.pauldavids... ), but I learned A LOT, especially about the official Android publishing process. I don't care if it doesn't get used by many people, because my target market was literally 1 person: my girlfriend.
In addition, the process of making this app was fun. Learning AND fun; a goal that ALL of us here are striving for, right?
Going after such a small niche is a great idea as long as you know that the market is big enough to provide good ROI in both percentage and nominal terms.
I don't think the worry from a competitor "adding a feature and crushing you" is a very likely threat. As long as you can stick it out for a few years to build a brand name and continue to keep in front of the indefinite stream of people learning regex you should be fine.
The company I work for (as an SOA architect) uses regex heavily for many mission critical applications. It costs me 100s of Ks in testing effort when a back-end format experiences major change. We usually don't find a lot of bugs in testing but each missed parsing requirement could mean millions to the bottom line thus justifying the investment in man hours.
If you think support of regex is a tiny market, I am not sure you have considered all of your angles or fully understand your market.
One think that I would really love is to be able to used named capture groups like in Python.
I read your blog post, and have kept named groups on my mind. Support for more languages is planned. However, I should note that it will be a premium feature.
I really appreciate the continued support.
I mainly use Go and am used to Go Playground http://play.golang.org/ for testing very small snippets and sharing them with others in IRC for education/debugging.
Debuggex is already part of my workflow when I write regular expressions, I was using it just yesterday to test some pre-processing of Markdown.
The value to me is already there, but right now it's something I could also do without... but if the regexp engine on Debuggex is the one that is in use in the language in which I wish to implement the regexp, then that does change everything. The value then becomes very high to me.
Debuggex can get you the first 95% of the way, but that last 5% of working out why something is not quite as you expect is where most of the pain is.
I generally find that the last 5% is implementation specific features and syntax (I have only settled on Go recently and tended to work in several languages at a time for the past 5 years, so most of my regexp pain comes from context switching languages and libraries).
Being able to select the exact implementation is the tipping point for me to reach into my pocket and pay.
Bad: The first and last mention of Debuggex in the body text should be a link to your product.
Please give this a read and let me know where the right place to link is, if not here.
1. You are giving me quality content about your business experiences and decisions.
2. You are giving me this information on a blog supporting a product which, by the way you've crafted the blog post, seems likely to be professional and loved.
3. I'm a person who makes and uses regexps, a HN reader and I want to check out the product. I want to do this easily. The web uses links to do this. You've earned the right to link. It is exactly when you should. It is directly relevant and it is in "your home".
If you are in business, this is why you wrote the blog post. You've got me right where you want me. I'm interested and I have money. Make the path between "he should have my money" and "he has my money" as easy as possible. Link.
Let me use a crude dating analogy:
1. Meet interesting person.
2. Invite person to dinner.
3. Groom, clean, prepare, cook, present, share dinner.
4. Goes well, clicks, everyone is interested.
5. Interesting person leans in for kiss.
6. You back away, saying the kiss would take away from the lovely evening.
The kiss, and the relationship it hints at, is the point of the evening.
And since I see the horse, while on the ground, is still kicking somewhat and not all the way dead:
You are in business or you are not. If you are, know this and live by it:
Do the prep work, then ask, ask, ask. The worst that happens is no.
You've got a great product. Good luck.
I developed torapp guilloche designer (http://www.torapp.info) for security printing industry, which is definitely a tiny market. But it did not mean less competition, and it is in fact much more complicated than a regular graphic editor like adobe illustrator and coreldraw.
Besides regular editing facilities in AI or coreldraw, I spent tremendous effort to handle all possible math formulas/curves as comupter algebraic system (CAS).
I would recommend people to pursue as big market as possible.
Yes it's a huge share of programmers, I'd say 80-90% for your first example 95%+ for your second. But compare that market to the market for Dropbox, or AirBnB, or Amazon.
If you're market is "programmers" it's already a pretty minute fraction of the general population.
A. to acquire a huge customer base and then pivot into satisfying them with a larger "suite" offering which includes your original service as a feature,
or B. to be acquired by another company with a huge customer base... and then integrate your feature into their suite. :)
I could see, for example, Github buying this (and other things like it) and launching a featureful, language-agnostic online IDE that compiles against Travis-CI.
While I would totally use this tool, this statement indicates to me that he talked to a specific subset of developers.
I know that's kind of what the article is about, but still, this sentence makes it sound like he has solved the biggest time-sink for software developers.
It's open source so feel free to "steal" from it :)
http://www.gethifi.com/tools/regex (js regex tester)
http://rubular.com/ (ruby regex tester)
Have you heard of/tried these before?
I don't think your product has a tiny market. Everybody uses regex and nobody actually understands it.
No. Scale has nothing to do with market size. Though you picked to build something (not yet a product) that seems to lack a market (defined as people willing to pay for it).
In a smaller market, you can demonstrate expertise.
Its actually easier to demonstrate expertise on bigger markets, due to its density. A small market can only have so many experts.
In a smaller market, you can iterate faster on non-programming skills.
This is more of an attitude than anything else. Its not a big vs small thing itself.
One question I have to ask is why are you trying to develop a new kind of product on an untested market, when you can improve on an existing product and just focus on selling? You are still picking the most difficult choice. And the one that usually tends to deliver a failure.
Once again for everybody: Don't build new things in new markets. Take old things and improve them.
May I ask you what you used for doing the layout ? All coded by hand ?
Good work anyway !