My Startup Failed, So We Open-Sourced the Tech
veniqa.com
veniqa.com
Repo: https://github.com/Viveckh/Veniqa
Thank you for sharing the work, will enjoy studying it!
Even if I don't end up using their solution reading through an open source project is, for me, a great way to think about the problem without all the pre-conceived notions I have regarding my existing code base.
Alternatively, porting to shuffle.js or filterizr (both MIT licensed) might not be too hard.
I do advise to be very careful about such things, and spend the effort to figure out the legal obligations that stem from transitive deps though. Not just for this project either, for _any_ project.
But agreed, you need to be aware of the license obligations of any code you use.
Your code is still under whatever GPL-compatible license you want, but the GPL component means you can only use the product under the GPL, so for example if somebody requested the source code of your distributed product under the GPL, you'd need to provide it, all of it, under the GPL or a compatible license. You cannot just provide the GPL licensed components.
The linked GPL'ed code seems to be client-side/frontend code, so at the very least everything client-side would fall under the GPL (if you want to argue the client(-side) and the server(-side) are different products).
[1] https://en.wikipedia.org/wiki/GNU_General_Public_License#Lin...
The Lesser GPL (LGPL) limits the reciprocity to the code itself, provided you're only doing dynamic linking or equivalent and not melding the code into yours (i.e. static linking).
Additionally, many hugely successful open source products started off with less-than-ideal codebases. The haters dont realise this because they arent interested in contributing anything - they just wait until everyone else does the hard work, and then adopt the product as their own.
Thanks for open sourcing something you spent the time to create. There are many who appreciate the time, cost and effort that takes.
I know software devs, myself included, are often too abrasive and forget social niceties. But far too many replies here are closer to insults, without even a vague intention to be constructive.
And as for their decision to open source it, why focus solely on the code that they're open sourcing, rather than the ongoing support and development they will be providing. Creating a successful open source project often comes with many of the same challenges in creating a successful company: you need to promote it, support the product and the community, and make a convincing argument that it's better than the competition.
I found the feedback here quiet helpful as highlighting a case study in what not to do when building a business.
Hacker News is not a marketing or promotion site. It is a discussion site.
I've hired a few developers and have found you can turn a inexperienced but relatively bright developer into a competent one with sufficient time and training. In my experience, this usually takes at least one year, and roughly one or two months of a manager/mentor's time. An experienced super-star can become productive within a month, requires just a few days of the manager's time, and can easily be >3X more productive than the merely competent engineer.
The problem is that it's almost impossible to identify most super-stars, and the obvious super-stars command super-star salaries (although generally less than the 3X productivity gain).
Creating a company that relies on training competent programmers may be less efficient than one that seeks out super-stars, but it's still a proven and workable model, with added benefits of higher employee loyalty and work-force stability.
I often wish there were more public post mortem on business models. Sharing the code is fantastic and I applaud you for it.
I'm skeptical of most of these post-mortems. They are generally written by the founders themselves, and therefore have a built-in bias to shift blame to external forces rather than unforced errors or a lack of understanding the product/market fit. Further, it's likely the founders probably don't know the true reasons why they failed because if they did, they could probably fix them.
That said, they do make for interesting reads, especially when read side-by-side with a similar company that did well.
at least you’ll never wonder “what if i tried to do a startup”
you only live once.
cheers. hold your head up high and ignore the armchair critics
It makes sense that there is a lot of skepticism in this thread. Most startup code is either solving too narrow of a problem or too messy to be useful when the startup is shut down. This appears to be neither.
And thanks for open sourcing your tech! I see some legitimate critiques in the comments here - "it's not production-ready but you claim it is", "you shouldn't have built your own e-commerce solution" -- but even if no one uses your open source project, people can learn from it.
On a side note, I noticed that you and your co-founders may be on H1-Bs , seems like you are working for Accenture - which hires a lot of H1Bs. If you are, be careful. Depending on your situation, you may not be able to own a business in the US. Most worrying part is the premium support you are trying to start may be seen as consulting. Specially advertising this, USCIS may find what you are doing on an H1B just by doing a web search on you. If you guys are not on H1Bs, then please disregard my comment.
Skimming the code it looks like mostly an overengineered CRUD/SPA with a lot of non-DRY code, possibly some security issues, and no obvious major game changer that would have made it worth building in the first place. And building it would drastically slow down ability to iterate on the actual business proposition of selling stuff, down to e.g. the HTML for customer emails hard-coded into JavaScript.
I sorta see this as the inverse of the no technical founder problem - it's the solely technical founder problem, where you're supposed to be focused on selling luxury fashion to South Asian consumers but that's boring and you'd rather be a cool startup writing your own e-commerce app using "MongoDB, Express.js, Vue.js, Node.js, Mongoose ORM, Redis", etc. Like seeing a nail and deciding to build a hammer factory from scratch to supply yourself with a single hammer.
There are companies doing millions of dollars per day in sales on Shopify or similar platforms. You should at least be at a significant fraction of that or doing something extremely weird before you consider DIY.
So instead of figuring that out as quickly as possible and building something of value... we're building a 'platform'. No one knows exactly what the platform needs to do, but management seems pretty sure that it needs to use gRPC for APis, table storage instead of SQL, an 'onion' architecture, a multi-stage data ingestion pipeline with more visio lines than I can count, docker, CQRS, a service bus for eventing, a micro-service architecture, no direct communication between services, and a SPA front end.
While it does seem enticing to get paid (well) to play around with new tech, it strikes me as a massive waste of resources and a huge risk. I just want to build something that solves a real problem before we run out of money.
> no direct communication between services
How does indirect communication work?
I've made a few similar design decisions in our tech stack, we have no "direct communication" between microservices, discounting the shared database. Microservices communicate through the use of RabbitMQ.
We build our system around the premise of eventual consistency, thus reducing the need of blocking computations.
So-far this has served us rather well.
E-commerce is hard, and getting the tech right is only a small part of it.
I work for a very large e-commerce company, and I’ve been building e-commerce sites myself for years.
My first attempt, in part, failed because I spent too much time trying to get the tech perfect and not enough on marketing. I should have accepted the tech was a bit crap and only tried to sort it once I had enough revenue to sort it properly.
In my experience crappy tech doesn’t stop a company from being successful if it’s got good product/market fit. It might slow things down or cause problems later, but the company will still function. Focusing on the tech before getting the business fundamentals right means an ‘It’s been an incredible journey’ blog post is imminent.
My rule now is to use off-the-shelf tech wherever possible, and only try and build something new if it provides enough value. Reinventing the wheel, only newer and shinier, is not providing value.
Using shiny/new tech is just complementary, and might even come back to bite you later on.
There are boutiques in NYC that sell 20-30k/week to SE Asia by being "showrooms" once or twice a week for 2-3 hours for QVC-like shows broadcast on chat platforms/TikTok/Instagram in native languages by 20 somethings who charge these boutiques 10-20% commissions.
I can’t speak for India but e-commerce in SEA is like it is everywhere else.
Also, it’s very doubtful that people shopping at NY boutiques at a premium would not be comfortable with English and that ‘native language’ would be worth the effort.
I live in SEA and when I want to shop — provided I’m too lazy to drive 5 miles to a JV, Polo, Fendi, Prada, Hermes, etc boutique — I can order from a local boutique / brand online.
No one I know cares enough about boutiques in other countries to pay a premium, risk sizing issues. Generally people affluent enough to try to keep pace with trends in other markets travel enough to shop in them in person.
Did you just make that up?
In the West we use credit cards and our payment systems are based around that. We do not do live video selling as a part of the commerce. Our platforms are optimized towards static image-based shopping carts with text describing products.
> Also, it’s very doubtful that people shopping at NY boutiques at a premium would not be comfortable with English and that ‘native language’ would be worth the effort.
They are broadcasting QVC-style out of New York boutiques to their viewers in Vietnam, China, India, Cambodia, Thailand.
> No one I know cares enough about boutiques in other countries to pay a premium, risk sizing issues. Generally people affluent enough to try to keep pace with trends in other markets travel enough to shop in them in person.
Good luck getting Dry Clean Only, BHH, Minions, Mia Vesper, Chen Peng etc by dropping by your local boutique.
100K per hour for 50% of the hours $432,000,000 per year. Total worldwide revenue of LVMH for 2019 is 53.7B euros. At 100k/h for 50 percent of the time it that mystery IG seller is at nearly half a percent of LVMH revenue.
If you can give an NYC boutique owner targeting a luxury market ability to sell 10-20k for 2-3 hours a week of their time based on your audience and you can replicate it across different subsections of a luxury market, you will be picking up clients until the cows come home. Of course not single client would actually be able to do more than 2-3 hours a week of sales at most because they simply won't be able to get the product needed to resell. The LVMH-like supply chain is corporate and it is not sold via random channels, so each of the successful luxury boutiques has their own developed contacts with the designers/producers who have very small ( measured in single digits ) manufacturing capacity ( it is however or maybe because of it commands LVMH-level and even higher pricing and higher than LVMH level margins).
Tech platform part here is 100% irrelevant. Building the sales platform on a top of shopify would have had the exact same results.
UPI is an interface that any bank or wallet app can use to allow individuals or businesses to send money to a mobile number or UPI Id.
It doesn't seem the OP was asking for a post-mortem of his start-up. It seems they were giving a gift to the community, by open-sourcing their work now that their project has come to an end.
To be fair, Shopify takes a huge cut, and retail margins can't afford that.
If I were them, I would have also made a homegrown e-commerce CRUD software as well.
BUT I would have used Django or Ruby-on-Rails. It would have been finished so much faster. And I'm not sure it would even be much slower than the Node/PHP solution.
The reason to make a greenfield solution is to plug in to the rest of your tech. It is easier to make it from scratch than to customize some third party e-commerce software. If you do not have any other software to plug in, and Shopify would actually fully meet your needs, then you should reconsider calling your idea a tech startup.
Grumble grumble costs grumble profits. Talented people don't stick around to maintain shopify workflow. Management needs to give people incentives to work, beyond a paycheck. Go ahead and refuse to recognize the fundamental needs of talented people. It's a great way for talent to reallocate itself to a place where it is more appreciated and supported.
That's not the fault of the company or the manager but the employee for staying in a job that does not line up with their long term career prospects. You cannot expect anyone to care about you except yourself. If they do then that's nice but don't expect it.
>If a manager fails to develop actual talent, that manager deserves the outcome.
You mean a successful company and stock options they can buy a house with?
If a business succeeds then it can use it's series B/C funding to buy better talent. Expensive to do but by then money is a lot less tight.
Then don't.
Unfortunately most of us think we're too smart for that.
Why build your own platform instead of Woocommerce/Shopify?
The countries we were targeting in south Asia were countries like Nepal and Bangladesh where debit card purchases aren't really a thing. Most of the transactions are still in cash, bank transfers that require using local payment gateways or locally popular app-based transfers (which resemble Venmo and Square Cash in the US). And also, we needed to use a combination of shipping services since worldwide shippers like UPS and FedEx don't ship to the doorsteps in these countries since home addresses aren't easily GPS-able due to organization issues. Some of us grew up in these countries, so we've experienced this personally. These were just some of the custom situations which wouldn't have been addressed while using Woocommerce or Shopify. So we decided to build our own platform to customize it as per our unique needs as we go.
Licensing
We would appreciate feedback on this very much. We went with MIT License since that seemed to be the only one that allowed people to use it without much restrictions. I admit I didn't spend much time on this, but now looking at all the forks and engagement, it is something that needs refinement for sure.
Shortcomings in the tech and tests
There is a fair share of shortcomings which we are aware of - like missing tests and antipatterns. We wanted to get the initial version to the market quick, so a good portion of the work was rushed. We're working towards addressing these issues now, since we never thought someday Veniqa would be open-sourced and others might end up adopting it. Also, the engineering team for 80% of the build was just two of us, and we had a third member join us after. With regular full time engineering jobs during the day, the only way to finish building Veniqa was through caffeine powered insanity of 15 hr coding marathons during nights, weekends and vacations.
Future Plans, Contributions and Developer Documentation
We are currently in the process of building test suites, docker images and writing extensive documentation to speed up startup time. Hopefully, so we can encourage code contribution from other smart fellow engineers like yourselves. Also, there are areas like shipping where the logic is heavily geared towards fitting our custom needs, we are looking to generalize that. In general, we aren't aiming Veniqa at people for whom Shopify or Woocommerce gets the job done. It is for the engineers or bedroom startups who have custom needs due to the nature of the business or want to use it as a baseline to speed up rapid development.
Any github issues, code contributions are all greatly appreciated.
I have detailed some of the lessons I learned in the process in this article.
https://medium.com/swlh/why-my-startup-never-went-live-despi...
I don't personally like doing much JavaScript/Nodejs development, but it'll be interesting diving into what it looks like for something like this...
As alluded to by some of the comments, this was probably a misguided effort for the original startup but could be worth pursuing by itself.
I believe this is how the likes of Slack, twitter and a number of other companies came to be.
Edit: Wow, so I missed this whole story: https://www.fastcompany.com/1837848/insiders-history-how-pod...
Of course, tests can help you achieve this kind of high quality code, and good tests have other benefits like helping you to prevent regressions when modifying the code, but you can still have high quality code without them and low quality code with them.
No tests usually good indicators that there will be a lot of repeated and overcomplicated code. Having a solid test coverage allows you to change/extract functions at any point when you see something is getting outta shape. With no tests, however, it's much easier and less scary to add rather than change.
People often make a point that writing tests takes time, but I'm pretty sure it slows you down in the beginning of work and speeds you up quite a bit when you amount some volume, and further you go, more you benefit from having a decent coverage. Also, oftentimes, especially on the server side, it's just easier to implement/verify with automated test from the start rather than by hand.
None of it is related to the OP codebase, just thoughts in the abstract.
I certainly hope that quality testing is more than just your preference or even a good practice: it's now a central part of software development. At this point, we know enough about the benefits of good testing to say that it's practically malpractice to not have them. Good tests may not be a strong enough signal to conclude that a project is good quality, but lack of tests is a clear sign that a project is low quality.
Also, I'm not advocating 99+% test coverage for new (startup) projects, but one could start with some tests selectively for core functionality or the most complex parts, and already enjoy a great overall benefit.
https://github.com/Viveckh/Veniqa/search?q=console.log&unsco...
Thanks for taking the time to do this.
Is there a directory of now public domain code / IP from dead start ups? 🇺🇳
But why would anyone use this?
Props to you guys for open sourcing it!
1. The service is a leaky abstraction, it knows about HTTP status codes and presumably the response body format. The point of separating concerns is to make code reusable, HTTP response codes don't make sense outside of a HTTP call. Similarly, any calling code needs to know that `sortRule` is expecting a MongoDB sort parameter.
2. The control flow is super unclear due to mixing async/await and Promise API coding styles. The `.catch()` call on the promise chain means that the `catch` block will never be hit and the API will always return OK, with the error object exposed to the client in the `responseData` - likely exposing implementation details about the server via the stacktrace on the error object.
There are other nits I could pick, but those are the most important issues and my other criticisms are more a matter of preference.
It makes sense that awkwardly hard coded hacks like this will exist in a startup's piece of software. But it's possibly full of similar things that might take a lot of effort to find, much less fix.
When money is running out and deadlines are looming its hard to have the discipline to not do stuff like this, and a startup's goal tends not to really be to build open source software for everyone to use anyways, so I'm not surprised something like this might exist.
[0] https://medium.com/swlh/why-my-startup-never-went-live-despi...
Claiming that software that never saw any real production traffic is "production-ready" is a bold claim to say the least. I dug into the code base and there doesn't appear to be _any_ tests. I really hope no one actually uses this application for anything real. I will say that the code does appear to look clean. But validating its functionality is a mammoth task that probably isn't worth doing when existing marketplaces/hosted stores already exist that undoubtedly do it better.
The author also doesn't seem to have any qualms about burning bridges either.
What is production traffic?
> I dug into the code base and there doesn't appear to be _any_ tests. I really hope no one actually uses this application for anything real.
Why? Plenty of great software doesn't include test files, and that's not a bad thing. Writing proper test files means you'll easily end up spending 2/3 of the time writing test code, and even after you've written all these test files, then you still have to do a lot of external tests as well. For instance, setting up external uptime services to ensure things are running as intended, testing everything is loading properly on multiple browsers + devices, stress test, etc. You seem to assume they've done no tests whatsoever just because they don't bother writing test files.
> But validating its functionality is a mammoth task that probably isn't worth doing when existing marketplaces/hosted stores already exist that undoubtedly do it better.
It's worth doing if you're interested in working with a similar stack. I won't comment on the server code since I haven't worked with Node (and hate JS), but the Vuejs client looks good.
> The author also doesn't seem to have any qualms about burning bridges either.
I agree, but the same could be said about you.
A company does not own it’s employees. It simply purchases their labour.
> I was too mesmerized working heads down with my engineers knocking out features and crunching out thousands of lines of code for a few months
Marx had this neat term "surplus value" to describe that problem.
I used to be in love with technology and built stuff in my own bubble. None of it gained traction. Then, I put less emphasis on tech and more on product-market fit and the let the two play off of each other. Obtained much better results!
They aren't selling software. And they aren't selling subscriptions. All they are offering is professional support.
It's just striking that the team behind the project calls their code "production-ready" despite it objectively not being true. Furthermore, they have the audacity to try charging for a support contract for what is undeniably going to be buggy code. Albeit I suppose it's still admirable they open sourced their code at all.
He didn't say you're not free to critique it. He asked that if you do, critique it in a useful way: don't just shame it, but instead articulate what exactly sucks and how it could be done better.
If you failed and are brave enough to show your failure to the world, let's appreciate that and learn from it, not bash it so that afterwards no one dares releasing anything anymore (not saying you did this, just explaining his point).
Kudos for opensourcing!
I suppose you can just ignore every issue and problem and security vulnerability that comes up in the future, or hope that contributors decide to fix things for you. Or spend countless hours of your own valuable time updating the system for some kind of mental satisfaction?
I love open source, I use open source, I like that this is open source, but I can't understand why people actually open source things.