I agree, I might not use it, but it's a good example of a real world product that I can learn from. Quite often when I'm stuck on something, I look for OSS to see how they've done that particular thing.
I especially like to compare with complete solutions like this repo. Because sometimes I'm stuck in a rut and looking in the wrong layer.
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.
Note, however, that this MIT licensed code includes https://github.com/Viveckh/Veniqa/blob/develop/website/js/is..., which is dual licensed under GPLv3 and commercial. There may be other such components as well. So tread carefully if you'd like to use this for anything practical without having to disclose the entirety of your source code.
This is the most concise reason why not to use this code. The rest are complaining about the code quality rather than the implications of the licensing issues here.
It's quite OK to use, if you do a review, identify all problematic dependencies, and license them under more "commercially friendly" licenses, or replace them with something else.
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.
What I wanted to point out is that just because software X is licensed under MIT or BSD or Apache 2.0, doesn't mean that all of its dependencies are, and therefore, that it's _only_ licensed under those licenses. I have observed several times in the wild people not understanding or appreciating the meaning of this crucial difference. That's a recipe for much regret later on when you think you can keep your trade secrets, and you legally can't.
No, linking GPL'ed code makes the product GPL'ed too, unless you're under the System Library exemption, another author-specified exemption or are actually using LGPL'ed not GPL'ed code.
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).
You're thinking of the Affero GPL (AGPL), which triggers the reciprocity clause on modification for network services.
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).
The thread is a case study in why not to open source your code: belittling feedback that serves little purpose other than to make the commenter feel good about themselves.
To OP: ignore the haters. They are happy to use closed source software and services with no way for them to verify the products live up to their high standards - they even mindlessly agree to those corporations terms indemnifying them from poor quality code and infrastructure.
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.
Constructive feedback useful. There are a few posts on here which are constructive. Point out some code you dislike? Okay, good. Comment on the general structure of the code. Okay, good.
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.
As a Dev, I don't care that the world sees my house is a mess if it means I don't have to rewrite some random component library or utility library again.
> The serious point is: why all the software engineering effort for just another e-commerce website, instead of focusing on sales since day 1?
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.
>The thread is a case study in why not to open source your code: belittling feedback that serves little purpose other than to make the commenter feel good about themselves.
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.
And yet your comment does exactly what you complain about - belittle a group of people, with nothing positive to say, to make yourself feel good. Can you not see that?
I see a bunch of wannabe open-source proponents complaining about code quality and doing nothing to fix the code quality itself. Complain all you want, but it does nothing to promote open source. You all have some introspective contemplation to do about how you conduct yourself as developers.
No it seems as though it just creates a bunch of complaining developers. This plays into another blog post that went viral on hacker news about why the interviewing practice is broken. Engineers who can't even engineer a proper interviewing process that doesn't nullify 99% of candidates and companies complain why they can't find good candidates. At least in the aerospace community the older Generation was willing to take on people who didn't know best practices and apprentice them. This is why hiring in software is broken. A bunch of people that don't actually want to be stewards of the craft.
> This is why hiring in software is broken. A bunch of people that don't actually want to be stewards of the craft.
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.
> Is there any notes on the business model, what worked, what didn’t, etc?
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.
I haven't tried running it yet, but it looks like pretty good code! It's modular and based on a stack that a lot of JavaScript developers want to use.
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.
Hey - sorry your startup didn't work out. If you decide to try again, I'm sure it will be easier :)
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.
I skimmed through the code. I share the sentiments from most people here that it lacks tests. But it does look like a lot of startup code I have seen before.
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.
Not to be a jerk, but IMO this is a good example of why not to build your own greenfield e-commerce solution for your B2C idea. They were a "a New York based fashion retail startup that served consumers in South Asian countries to shop from luxury western brands" so it's entirely unclear why their own in-house e-commerce platform would be anywhere near enough of a value-add to be worth the investment.
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.
This perfectly describes how I feel in my current position... and why I signed an offer letter this morning to go somewhere else. We've hit hard times and no one seems to know exactly what we need to build to bring in new revenue.
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.
Is no direct communication between microservices necessarily a bad thing?
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.
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.
Their issue was that they were selling to South Asian countries and they thought the commerce there was done the way the commerce is done in the West. It is not. It is video and instant messaging with QR codes to buy.
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 guess you mean South Asia (which really just means India) and not SEA.
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.
> I can’t speak for India but e-commerce in SEA is like it is everywhere else.
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.
On the contrary i have seen a lot of growth in live video based sales in the US, the younger generation seems to really like it. Ive seen IG boutiques move $100k in product in under an hour, many times.
This is the exact reason why tech people fail at business - their numbers are way off scale.
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.
Traditional e-commerce is absolutely ubiquitous in SEA. Their primary e-commerce channels are web-page and app-based shopping carts, just like we have in the west. While it’s typical to support local payment methods, most sales are processed via credit/debit cards, just like in the west. Non-traditional channels certainly exist, but they are absolutely a fringe channel. Tupperware Parties are still a thing in SEA (although they’re mostly for MLM products), and a lot of businesses will let you order via DM, but those sales are nothing compared to the volume on sites like Shopee, Lazada, Tokopedia... They caught on a bit later than the west (I was personally involved in one of the first major e-commerce sites in a particular SEA economy), but their growing middle class does online shopping pretty much exactly the same way we do.
In India, we use similar e-commerce platforms to the West and are probably more advanced in the payment infra with the advent of UPI (Unified Payments Platform).
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.
UPI isn't more advanced. It's just different. If there is a compelling value preposition for it to disrupt credit card payment processing, it will be adopted. The financial incentives have to exist, though.
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.
> There are companies doing millions of dollars per day in sales on Shopify or similar platforms
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.
It’s obviously not precise. But roughly after that you are making about a million a year minimum in cash flow and can think about spending $250k+ on custom software.
This company was fortunate enough to have sufficient talent to build such a system. If they were forced to use shopify, they would have had another 11 months out of the year to do something productive with their time. This system may be the v2 that was created following a shopify v1.
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.
Talented people being paid a lot of money to do something of little value (versus other cheaper approaches) is not a positive. As a business, the goal is to not to employ talented people but to make money. If the former doesn't help the later then that's okay.
What talent is anyone developing with third party api glue work? Third party api talent. Spend years in shops that buy rather than build and you will have a major skill deficit when you move on and want to do more in your career. If a manager fails to develop actual talent, that manager deserves the outcome.
>Spend years in shops that buy rather than build and you will have a major skill deficit when you move on and want to do more in your career.
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.
You seem to think that there was a better use of technology than what was done in this case. I argue that there wasn't and that they did the best possible thing they could do with tech resources. The business failed despite the tech decisions. Now, the developers have something to show for their work, and valuable skills that others will pay to benefit by.
Unfortunately for the company in question and all those that will surely come after is that advice and more importantly the humility to hear that advice came too late. ~sigh
Thanks for sharing,
Personally, I don't find myself using it if I do e-comerrce stuff,but It is really good head-start for someone who want to learn how things work in real.
And best of luck for any future work.
Thank you so much, everyone, for your feedback! Appreciate the encouragement and constructive criticisms equally. We understand and share the shortcomings you mentioned as well. As one of the co-founders and the key person to take the blame, I wanted to answer some of the common concerns and admit our weaknesses as well.
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.
It is wonderful you were able and willing to opensource the IP after the startup didn’t succeed. More founders should try to do that and plan for it when raising financing - including in investor rights documents or the company’s charter.
Thank you for doing the awesome thing and making your stack Free Software. It would have been great if your startup had succeeded and you did this, but it's great that you did it nonetheless. :)
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...
Maybe it's very readable, but in some circles production code with no tests is considered per definition low quality. Or: if there's no tests, the code "doesn't exist".
That seems pretty absolutist. Tested code is only as good as the tests themselves. I'd take readable, reliable code which covers all the corner cases over tested code that doesn't actually work reliably any day.
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.
in my experience, taken from projects I worked on with and without tests, even bad tests are better than no tests at all.
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.
> 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.
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.
let me guess - the people in those circles work for either already-profitable companies or companies flush with venture capital, rather than a company trying to get off the ground before it runs out of money?
I have worked for either established and startup companies (admittedly with varying success). I think it has more to do with the composition of the team. As engineers there are a lot of different experiences we can bring to the table, but some of us have had the transformative experience of being on projects where the testing was right, in how to do and the amount, and we have seen how it helps us on a daily basis to move faster and be humbled by the bugs that we'd otherwise have released, or that we'd otherwise would've had to troubleshoot on a remote system rather than fixing them minutes after creating them. I'm now making it a point to expose my team members to the same awesome experience. But I also understand that, as you're building a startup team, and there are many things you have to get right, this may be a skill you would go without.
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.
What about the myriad of try catch console.log. With the statement in the readme "Database & file-based logging" unless they are overriding console, then I don't even know what they mean.
I'm not sure what codebases you've worked on, but this is hardly "mediocre" in any sense of the word. It's highly organized, consistent and modular. The toolchain is modern and set up well. The code is easy to read. There are folks the world over that would find working in this codebase a joy, and would be able to easily jump in and start contributing at any level of the stack.
I think the controller/service abstractions are completely unnecessary and cause unwanted indirection. Otherwise, this looks like a typical CRUD service -- with custom logging, database model schemas, authentication, and routes that utilize all of the above.
You're assuming quite a lot. First, I'm not saying it's broken, so what is there to "fix"? Second, I'm not using this library, so why would you expect me to submit a PR?
People aren't expected to contribute to libraries just because they noticed a smell in the code. Open source is about contributing to stuff you use. You don't have to (and shouldn't be expected to) fix everything you see broken in in the world.
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.
Are you even going to write a line of code to fix any of the 'awful anti-patterns' you mention or am I just going to get downvoted on Hacker News. For Christ's sake, this is why open source is failing. You all like to complain more than you actually do anything at all to fix things. Exactly the reason I never open source a line of code. There is no true community it's just a bunch of wankers that would rather complain about anti-patterns then make things better. Fuck.
How would someone judge the code quality and architecture to say this repository is a good example and how? Wouldn't the general tutorial and training material be a better source then a startups ship it now code base?
The code itself doesn't have to be good to be a good example. One thing the average tutorial doesn't have is complexity. Picking apart how this code handles complexity could be a good lesson to people who are trying to learn how to architect good sized projects.
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.
A more in depth analysis as to why the startup “failed” can be read here [0]. Thanks for your contribution to open source Viveck and good luck with your various projects.
> We had a production-ready suite of apps built from the ground up over the past few months, but as we got closer to launch, the incompetent work from other teams started to become painfully evident to proceed any further.
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.
> Claiming that software that never saw any real production traffic is "production-ready" is a bold claim to say the least.
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.
Yeah the tone of that entire article struck me as very arrogant. Even "small" things like "my engineers" -- I don't think I'd want to work with this person.
You obviously don't understand your position in the economy then. As an engineer you are a comodity. As much as you would like to deny this fact you still are. Why do you think that you make a salary and the companies make hundreds of millions or billions!?!?! The tone of your comment struc me as very arrogant.
That's a very odd way to view a generic term. I don't own "my friends" but I wouldn't think twice about saying "my friends went to the bar last night". Similarly for "my co-workers", "my manager" or "my uber driver". Just because someone used an uncommon expression, does not mean they have some nefarious intent behind it. Especially when the context is completely innocuous
> 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
Keep downvoting. You tools are creating a feedback loop algorithm without writing a line of code and yet you complain about this very thing. Hacker News is dead for constructive debate. Instead of responding you cower behind a downvote. Damn, seriously!?!?
Calling your coworkers "incompetent" in the second paragraph is.. a look. Especially when talking about false dependencies and over-engineering an MVP. A complete lack of pushback from engineering will lead to teams taking a dependency on engineering building the whole world, but this problem isn't just a "them" problem - pushback on expensive asks is a necessary part of business.
What the article expresses is what I have also gone thru in my personal journey as an entrepreneur as well.
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!
Shame, shame, shame, on every detractor to open source here. The code may be crappy but at least someone released code to the public and they get to learn from it. Why don't you all write a blog post on the intricacies of how shitty this code is so that future developers can learn what not to do. Your negative responses are shameful. And you won't do a write-up since you are a lazy to begin with!
There's nothing wrong with open sourcing bad code---we do live in a free world after all. But much like they were free to open source it, I'm free to critique it, not use it, and not support it.
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.
> "... it's a free world, I'm free to critique it"
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).
Every comment of yours in this thread is insulting, negative, critical and - in your own words - commenting like that is shameful. What are you trying to contribute by calling everyone else who comments lazy arrogant wannabees?
So, not only did it not make enough money for the business to run, you decided to support it for forever for free as open source?
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.
Open sourcing your code in no way means you have to maintain it. Anyone can fork the repo & add their own features/fix issues. If you want them to make changes, they seem to have their development services on offer.
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.
https://vestride.github.io/Shuffle/
https://yiotis.net/filterizr/#/
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.