You have to toe the line a bit in startups, you want to use proven technology but leave room for the employees to feel like they are contributing to something new and unique.
It's such a difficult line to toe. Especially because people like working with new technology and it does seem to help with recruiting even if it makes actually operating the business harder.
Some people like working with new tech; in my experience most do it not because they like it but because of their resume. I like how I can get really good, cheap and experienced devs for ‘non hip’ tech because they do not want to work with new tech, they want to improve their skill on what they know; java/spring, c#/asp, django etc with jquery/bootstrap. Resume driven/recruiting forces them into all the new stuff but they rather take a pay-cut to work with the stuff they know and are good at. I need stability in software and my teams over the years; the continues race for the latest and greatest helps me do nothing for my business (making profit that is), including recruiting. Quite the opposite in fact.
> they want to improve their skill on what they know
for me it's quite the opposite.., after around two years of working with some tech I feel like I can do anything with it and it becomes boring for me making me want to try something new.
but yeah my mindset always was being the jack of all trades, which is very good for small startups and not a good mindset for corporations which I avoid..
I'd think that one of the advantages of working at a startup compared to a more 'corporate' company is the increased autonomy. If you don't get more creativity over the solution, working in bigcorp surely has more advantages.
I also think the "sense of ownership" part that comes with making decisions like that is important. With a startup, it's beneficial if contributors feel they're able to fix problems they see proactively.
But, yes, I don't want to work with hype-driven or resume-driven coworkers. Yes, I want the choices to be pragmatic and well-considered.
There are still near infinite amount of good ideas outside of the mainstream that are new and exciting to most people, that are still well explored, have long histories and are mature.
Kube is great. Abstracts away lots of problems. If you make a single kube cluster (which is trivial with eksctl) you can iterate on a number of startup ideas pretty quickly on it.
The kube API (the pod/deployment/service/ingress structure) is where the magic is, imho. Sure you could just make an EC2 instance, and swap in your Rails, and redirect the ALB and fix your domain CNAME, but whatever man, you can do like 4 of those things in an instant in Kube.
Good at smaller scale, and Heroku can go pretty good at scale. But eventually you run into things that they make harder rather than easier if you need to do something which doesn't fit well with their model. Deploying onto Google Kubernetes Engine has a bit of boilerplate setup work, but after that it's not a huge management overhead considering everything it gives you.
Okay, yeah, for sure. I think they're better options for early iteration. I guess actions speak louder than words here since my preferred operational stack is Rails + Typescript + React + Redux + Heroku w/ Heroku Postgres.
Yeah, definitely Heroku over k8s for idea validation.
I think there's definitely room in the k8s-based space for slightly past that, though.
I use the Jojoma framework to abstract away all that Kube stuff. It's trivial to use through Baobab, especially if you use the Wazabi framework-as-a-service framework (which you should). All you have is to deploy the proclets through a DMVC and it's all automagic.
I iterate through 17 startup ideas a day using that setup.
- If your business doesn't rely on new technology, then avoid bleeding edge tech (examples: you retail co-working space, rent apartments, do food/grocery delivery, etc.)
- If your business model does rely on new technology (examples: airlines in the early 20th century, railroads in the early days of the steam engine, e-commerce in the early 2000s) then you have to work out a way to deliver on bleeding-edge technology. That's where your competitive advantage lies and that's where the nice margins are.
Though even in the latter scenario, it's still prudent to narrow the scope of your bleeding-edge tech as much as possible (e.g. if you're doing a cryptocurrency app, you probably shouldn't be trying to make your own NoSQL database at the same time).
>Though even in the latter scenario, it's still prudent to narrow the scope of your bleeding-edge tech as much as possible (e.g. if you're doing a cryptocurrency app, you probably shouldn't be trying to make your own NoSQL database at the same time).
Nonsense, the database is the back up plan so you can pivot to a DB company if your main thing doesn't work out.
Or pivot to "we're a blockchain-based database". And when that fails, "we're a blockchain stored in a database". After that, you'll have to get creative with the neologisms: "we're the first ever datachain backed by a Baseblock".
Atleast in India its gone completely,
Here they started with a blockchain( just a database stored on a central government servers) for everything.
After crytpo currency got banned here and now i don't even hear blockchain anymore. People can't even differentiate between blockchain and Bitcoin lol.
Thankfully yes. I work in the space and we're starting to see projects/products roll out, without the high number of scams we saw in 2017/18. Hopefully by the next time the hype-train starts there's something there to be hyped about!
Make your own pencil factory for the stationary cabinet too, as a backup plan. Buy a coffee plantation to fuel your devs caffeine habit, which can be monetised if the main biz goes south.
There are these geniuses that can do something they never did before and create something truly amazing. But realistically even they don't manage to deliver on that the majority of the time.
Even the steam engine people had to rely on known standard parts like screws and bolts and known planing or manufacturing procedures that they didn't invent. Only because they knew which forces a bolt would withstand and learned from (at times catastrophic) failure they were able to even have a bleeding edge.
The standarized screw was after the steam engine. It wasn't until 1841 that Whitworth promulgated his thread. Before then every rail manufacturer had their own house standard.
> If your business model does rely on new technology (examples: airlines in the early 20th century, railroads in the early days of the steam engine, e-commerce in the early 2000s) then you have to work out a way to deliver on bleeding-edge technology.
Also, if your business model does rely on new bleeding edge tech, avoid all other bleeding edge tech. Pick one thing that nobody else can do, and do that. Don't try and create everything at once unless you have ridiculously deep pockets.
I disagree. There is always a space for something bleeding edge. Your fatal flaw was not creating something "new" but the fact that you didn't actually build the product. A product that has no easy ability to integrate with a workflow is not a product, it's a proof of concept.
I tend to agree with this sentiment and it's what's driven me to build the mvp for https://sqwok.im. At least for this type of app/product, I don't believe a simple poc would be enough. I needed to get a working mvp into peoples hands to even have a shot of conveying the idea. Some people close to me have challenged me on this topic, which is healthy, but we will see how it plays out.
A lot of the problems stem from just constantly changing the tech.
I used to work for an organization that has a team of mostly Java developers. They want to move to Python, in part because the big guys (Google, Netflix, and NASA as cited by them) did it too.
They are just building a run of the mill web app, but they are changing the entire stack for a new project that next to nobody on the team knows well.
Lol. I'm an embedded engineer, and this week I'm getting my coworkers excited to upgrade part of our system to use bleeding edge technology from the mid 90's!
Low end cortex-m cores are pretty cheap these days. More modern designs and processes use silicon more efficiently, so you get more capability for the same raw material cost. Also, you can do a surprising amount with an 8-bit MCU. Lots of very capable 3D printers still run on AVR based controllers. Often times, you're limited by peripherals or memory size more than raw CPU speed.
As a baseline, it's relatively easy to make an autonomous aircraft that follows GPS waypoints using an atmega328 and have CPU cycles to spare, even using software floating point math everywhere. All the open source drone firmwares recently dropped support for orders of magnitude more powerful cortex-m3 flight controllers, though, and are encouraging folk to migrate to cortex-m7 based controllers. That's crazy! Software tends to expand to fill up any available volume over time...
Really... I wonder what the spare cycles are doing, whether it's truly waste and bad coding or if it's doing some kind of sophisticated predictive algorithms that we're unaware of. I do try to assume engineers did something smart, maybe there's a good reason...
I really hope the reason isn't "so we could run the mainline linux kernel" or "because we needed a RTOS" or something similarly bloated.
There is tons of human value in doing things good enough rather than perfect.
Why implement quicksort when bubble sort will give you the result you need just as "instantly" and be easier to verify?
Why bother procedurally iterating line by line through a 1GB of text in python, when you can call f.read().split("\n") inside a list comprehension and probably have it run just as fast because you have a 64-bit 4Ghz superscalered mmxzomg Inteliapple CPU and 32GB of RAM.
Often times, the bloat is an intentional tradeoff to make something else better. More accurate code, more readable code, more configurable code, etc. Other times, it really is just bloated, more terrible code; even that has some value, if it meant that someone was able to contribute a useful feature that they wouldn't have otherwise been able to due to lack of skill or domain specific knowledge.
Ah, I would have thought it was more like "feedback loop" going to "feedback loop with DSP" going to "feedback loop with DSP with wireless" or similar.
I think I am thinking more specifically about the flight feedback example compared to what you are describing, but I'm definitely all for using cheap powerful ARM chips in place of obsolete stuff. I'm just hoping that most of that spare computing power was used for something cool and not just spinning the wheels.
Often spare cycles can be used to sleep the cpu for longer cpu intervals and save power. Faster processors are often more efficient per watt, which can save a bit of power.
More advanced DSP takes more cycles. Eg moving from fixed low-pass filters to motor-rpm-following-notch filters gives lower phase delay, but requires getting telemetry from motors, running multiple harmonic notch filters on each channel. Supporting a wider range of protocols and peripherals takes more flash space. And eventually, when it gets complicated enough that you can't enforce deadlines everywhere, yes, you need an RTOS.
I'm not disagreeing with you, but I don't think it's usually as simple as that for anything useful of non trivial complexity.
Most of the time, more power also brings more complexity. Cortex-M7 mcus, for example, typically can't reach their max CPU throughput without turning on instruction and data caches or "Tightly Coupled Memory". Data caching opens up a whole can of worms when interacting with memory mapped peripherals. Some MCUs with data caches have peripherals glued to them that are fundamentally incompatible with caching, leading to having to use indirect tricks like using DMA transfers to interact with them. TCM partitions your available memory space, leading to arbitrarily complex application specific linker scripts.
Newer chips are sometimes less capable on different axes. It's easier to use a 5V chip to interact with a 5V circuit, rather than a "better" MCU that is only 3.3v tolerant and requires a filtered 1.8V power rail for its internal circuitry. More complex CPUs generally have less predictable and potentially slower interrupt timing too.
Spinning new hardware also isn't cheap like spinning new software is, both in terms of dollars and in externalities. A popular community maintained firmware dropping support for an old but popular hardware generation that's become burdensome to maintain due to incremental feature bloat may be perfectly justified by the volunteer developers, but it does effectively turn that old hardware into e-waste. A company producing widgets with embedded components in it might want to defer the risk and schedule hit of switching to a new MCU architecture for as long as possible, in order to balance overall company goals and limited engineering resources. Justifying engineer months of work "because it's better and everyone will like working on it more!" is a lot tougher to prioritize than "because we only have enough stock left for 6 months and then we're scraping ebay".
At least for drones, the move has been driven equally by flash space as compute. And the performance really has improved! Moving from fixed filters to rpm-following notch filters for example. Supporting wider range of peripherals and protocols. None of this comes for free.
PICs have extremely low latency interrupts compared to ARM, as well as the assembly language being really simple. 8-bit MCUs can be really great at some things where ARM isn't just overkill, it can almost be a problem.
PICs and assembly are honestly pretty great, if you know how to use them like that. I've never actually used C on a PIC because they are so resource constrained, but they certainly do have their uses.
I just went and checked, I switched our main product over from ARV Megas' to ARM Cortex in 2013. The only downside is that the ARM's don't have as good sleep current as AVR's do. And they don't have internal EEPROM.
Other than that they are faster, cheaper, and have more RAM.
Seems to be this article is about when your product is bleeding-edge tech, but people are commenting as if it were about building your product using bleeding-edge tech (in-house or otherwise).
Yes, the article is exclusively about the trade-offs when building bleeding-edge products, like how impossibly hard it is to sell in to customers who have no idea what the product is or why it exists.
All of the comments for some reason are about not using latest-nosql-db-from-producthunt in prod.
I think the latter topic is generally more fun to commiserate about than the former. I have empathy for anyone that ernestly tries something ambitious and fails, and I'm glad the author found insight from the experience. Reading the article though, it sounds like the startup didn't really have a clear direction or momentum, tried to fix it by pivot ing to something technically "cool" without any business plan or realistic customer stories in mind, and then ultimately failed to create a sustainable business from that technology. A good lesson to learn from others rather than first hand, but not great subject matter to light heartedly banter about!
Yeah, it's kind of like the classic "break one law at a time" rule. If you're hauling drugs, don't speed. Getting away with just the one thing is hard enough.
>Discord has never been afraid of embracing new technologies that look promising. For example, we were early adopters of Elixir, React, React Native, and Scylla. If a piece of technology is promising and gives us an advantage, we do not mind dealing with the inherent difficulties and instability of the bleeding edge. This is one of the ways we’ve quickly reached 250+ million users with less than 50 engineers.
>Embracing the new async features in Rust nightly is another example of our willingness to embrace new, promising technology. As an engineering team, we decided it was worth using nightly Rust and we committed to running on nightly until async was fully supported on stable. Together we dealt with any problems that arose and at this point Rust stable supports asynchronous Rust. The bet paid off.
(They also mention how they're careful to replace decoupled components incrementally, and only where it addresses a real need, rather than for the fun of it.)
> Yeah, it's kind of like the classic "break one law at a time" rule. If you're hauling drugs, don't speed. Getting away with just the one thing is hard enough.
I wonder if not speeding is enough to give police officers a reason to make a drugs search in some places.
Czech here, I was stopped by the police once in the night on an empty 4-lane road doing exactly the speed limit. They breathalyzed me, looked at the zero and one of them said: "you know, when someone keeps the limit at midnight on this stretch of the road, they are usually drunk".
What problem was Discord solving when they launched? Twitch already existed, Slack existed. Asking because it's a similar question I'm asking myself as I build https://sqwok.im, a news-focused public messaging app. I chose to use "bleeding edge tech", and have been challenged by peers about whether it would have been wiser to just use some off-the-shelf solution for parts of it vs architecting a fully custom a-z platform. I guess it depends. I don't see a site like Discord or Sqwok having a chance without a certain threshold of engineering to support the early product. That said, there's always the chance it doesn't matter because it's not solving a pain point for users. Sometimes it feels hard to answer without a tangible product to show.
From my experience only, Discord was the successor to softwares like Teamspeak and Ventrillo for gamers, built as a social tech experiment. It also always had a FUN component to it, so it incentives creativity and people not taking stuff too serious. Children/teen seem to like it a lot.
Discord was heavily marketed towards the gaming community that was split between Skype, Teamspeak, Mumble and maybe some others that I don't remember. All of them had some flaws while Discord just worked.
* Skype sucked. Voice call audio quality was unreliable, managing lots of disparate groups sucked, if you had some random join your raid group (its initial market was FFXIV raiders as the initial team had previously worked on FFXIV utilities with guildwork) for the night you didn't really want to add them to your group chat for a voice call, it leaked information that was actively used to DoS people.
* It's users were consequently having to use multiple platforms, with teamspeak or vent or mumble for voice chat and Skype or Facebook for persistent text chat. This was inconvenient adding everyone twice.
* It's hard to explain how much it helped for the "bringing a random into your gaming group" scenario. You could just drop a link into the games text chat and people could join for the night and you didn't have to worry about if they had teamspeak or mumble or whatever installed.
* Teamspeak's free tier had a limit of like 10 users known to the server. Discord did not.
* Slack wasn't a competitor for Discord's initial market. Having to sign up for each instance was a deal-breaker. Discord originally allowed guest accounts, and I think it still does. Also the overhead to creating/managing a new server and adding people is really low comparatively.
* Discord doesn't really compete with Twitch much? People stream to their friends sure, and I have known people who had unlisted twitch channels for like jackbox in the past but that's a relatively late addition, and twitch is much more interested in the big streamers than the long tail anyway.
Obviously discord have significantly expanded their market a few times from FFXIV raiders to all mmo players to all gamers to everyone, but they started with clear problems to fix and fixed them well
Thanks for the solid recap, for some reason I forgot how voice chat was a big focus of Discord in the beginning. That might be because I mostly use Discord for non-gaming oss servers where voice chat isn't really a focus, and rather it's just a chat app.
It's interesting how they started out focused on gaming and have since moved away from it. I discovered a new Discord competitor, Guilded.gg, that sprouted up with marketing claiming Discord has abandoned gamers and they're going to recapture them.
It just goes to show that you never know which direction it's going to truly move and you have to be able to pivot. But having a core initial user group that you solve a problem for is key, and having a working product is key as well.
Had a $4 mouse from the dollar store. Watched some youtube videos, and decided to splurge and bought the latest and greatest bleeding-edge Mx master 3, at $129 and 3225% more expensive. Despite all the great reviews and hype. I'm kind of hating it. Damn thing is so heavy.
It feels like I'm moving a brick around. Was going to return it, but now I'm saving it for a protest.
I love the weight too. However, the battery life sucked -- last time I had one, kept dying after a week needing a recharge. I then bought a Logitech Marathon mouse and I'm already going 2+ years wireless on a single set of AA batteries. That makes me happy. I like products I don't have to think about charging all the time.
I wish they covered the mice in solar panels like the solar-powered wireless keyboard, or harvested kinetic energy though -- that keyboard is another great Logitech hit if your workspace is near a window -- you never have to charge it.
If you didn't buy that used, you probably should've complained to logitech. My master 2 runs ~1 month on a single charge, and when I see the third light blinking I usually just plug it into my laptop overnight. I've not had to deal with a dead battery in this mouse, ever.
Yeah it was new. Weird. Did you have to install any drivers to get it to power save efficiently? Because I run Linux and don't have any Logitech proprietary drivers installed.
I know I'm comparing apples to oranges, but I own a Logitech MX Anywhere 2S and the battery seems to last forever, even with constant use. It works on any surface, too! The best mouse I've ever used.
Also only had random $5-$10 microsoft basic mice since like the early 2000s, changed to gaming mice and didn't like any of them, and my last trial the mouse broke after a few weeks (logitech g pro).
Best mouse I've found is the Logitech G Pro, it annoys me that it's full of stupid RGB lights, but it has the precision and speed of a good gaming mouse without being too ridiculous in design or cost ~$60
I use a Logitech G502 and it's great. This is the second one I've had (spilled drink on the first one, RIP) and I'll buy the same again when this one dies if they're still around.
That Logitech mouse shape is basically perfect. I've been using mice with that body profile for 15 years now. I periodically check up on the newest iterations to have my replacement bookmarked, but this decade old one seems content to keep chugging on.
As a Vegan, I'm repulsed at throwing dead fish at people. Also they kill dolphins when they catch them. Dolphins are "people kind" best friend in the ocean.
On mobile it's impossible to understand what they do. Two words and then a screenshot that's impossible to read. Maybe that's why they've failed as a company. If you can't even make a reasonable homepage, what hope do you have in B2B sales.
My understanding: I want the components in my design system (e.g. Figma) to match the components in my front-end codebase (e.g. React) exactly, this tool helps me understand the current diff between the two.
From what I can see, the paradigm of component-based design has been growing in popularity since the tools like Figma have been improving rapidly.
In that case, it's a product for a niche and growing audience. I think the website hits some of the main points pretty well.
> My understanding: I want the components in my design system (e.g. Figma) to match the components in my front-end codebase (e.g. React) exactly, this tool helps me understand the current diff between the two.
This is what should be at the top of the the main page of their website if it's correct. Because endlessly scrolling hoping to find out what problem a product solves isn't a good way to sell a product.
Has any of commenters read the article? Looks like everyone talks about using bleeding edge tech in startup and how its bad, but this article is about building a bleeding edge product and how difficult is to sell such product (probably because everyone know that using bleeding edge products is dangerous :) )
Thanks for this comment! I usually read the comments before the article and though it would be a Captain Obvious advicicle with snarky comments as are the comments here. So I wasn’t even considering reading it.
Glad someone took the time to read the damn article lol
I actually started reading the article, which sparked my interest at start, but then faded away.
so I thought: "This is going to be one of these articles where the comments are more interesting than the piece itself" and came here, just to find the excellent: "did any of the commentators even read the article?"
Not even about bleeding edge products. It's a lengthy article about the pitfalls of entering a market with no market validation, which the author slapped lipstick on and gave this sexy title.
Exactly, its a classic we have a solution, but not a problem-to-solve let alone a product (yet).
“But guess what, they had no idea how to use our tool or integrate it within their workflow. And to be honest, nor did we. Adoption was bleak and feedback was dry—silence in startups is not golden.”
I had my first startup fail in the late 2000s because we built a sales prediction software that sounded cool, but nobody actually wanted. We even had a large paid pilot with a major auto manufacturer, but they didn't renew when it turned out that none of their employees had actually used the software.
Making something nobody wants is a classic startup mistake. I resolved not to make it again and read a great deal about market validation and building products.
I have one recommendation for those reading this thread: Steve Blank's "Four Steps to the Epiphany". It contrasts Product Development (focusing on a product with no customers) vs Customer Development (focusing on customer problems and building software around those). Honestly you don't even need the whole book, there's a PDF with the first couple chapters floating around [1]. I had a bunch of "holy shit, that's exactly what I did wrong" moments while reading it.
Eric Ries' "Lean Startup" is also an excellent book on this topic.
Someone on HN once said “It’s hard to tell people the solution to a problem they don’t have”. Building software that solves a problem that the intended users don’t understand that they have is also a real problem.
Yeah, creating problems in people for which you conveniently sell solutions is the job of marketing.
As for building a solution to "a problem that the intended users don’t understand that they have", I'll agree that this may not be a good thing for a startup to do - but when I see how basic research is being defunded and drowned in red tape, and people saying that startups are the new, distributed R&D departments, I feel the middle has fallen out. When startups do a greedy gradient descent, and academia struggles doing science, who's going to work on solving problems that require solutions one or two steps beyond what the intended audience can understand? FLOSS community? What about outside software?
I should clarify that I see nothing wrong in solving a problem people don’t realize they have, and to be fair, this is what startups often do. However, many/most developers see marketing and sales as something unnecessary, eg. “How hard can it be”. And they realize that it’s pretty damn hard when it’s already too late.
First off, they hijack your scroll wheel and present you with some Apple-esque website that is very slow and doesn't work properly. > "Remote, component-driven, and obsessed with speed." I think not.
Second, they show zero screenshots of the service or what the benefits are to using it. > "Handoff reimagined." Yea, okay... Nice slogan, now show me before I move on!
No wonder they're having issues convincing new customers. They think they're selling a space ship when really they only need to improve their website copy.
Yeah, as someone who might use this product I feel like the landing page should be a long post on “how it works”. Frontend engineers are going to be very big stakeholders on this and I need to know, down to the bone bits how does it’s thing.
Also the "bleeding edge product" in the article is some kind if analytics system that tells you the adoption rate of "components" (web widgets? Not sure) in your system. This might not exactly be what you think of when you hear bleeding edge, so take this article with a grain of salt.
Yeah, I read the piece and couldn't believe that this was the "bleeding edge" product they were referring to. At one point they call it "niche" themselves, which is a more accurate description.
"As designers and engineers, we knew of a rather niche problem: if your company has a design system, it's practically impossible to know the adoption rate of those components in your product."
Yeah, and I've never met anyone who cared to be honest. And if you do care, your answer is usually a quick "git grep" away.
As 'CPLX says, for many of us the article itself is just a discussion prompt. Quite often (I'd say half of the time), the tangents and off-topics in the HN discussions are way more insightful and interesting than the submitted article.
Which makes me wonder, why people insist on having a headline AND an article in 2020?
It only creates a confusion when most people don't bother reading articles when the headline is strong enough to inflict a response. It has become a tool to say something and deny saying it.
That got me thinking of an idea for a startup: let's build a service that allows people to broadcast headlines with no content (since no one reads the articles anyway), and then other people can reply to the headlines. To make sure that authors stick to the rules, we'll limit the length of each headline to 140 characters. Side benefit: users can post their headlines via a single SMS message.
I thought I was so clever and was going to reply "you've invented Twitter!" and then I read the rest of your comment, and realized that was your point. Damn it.
The headline is there to make you want to click on it and view the article.
The article serves two purposes. It's primary job is to be a scaffolding for delivering advertisements to the reader. The secondary purpose is to be a word soup that makes the article appear in search results related to some popular topic.
That's it. Many people don't realize that the job of a headline is not to be truthful, accurate, or even sensible. It only has one job to do: make you click through, so that ads can be shown to you. Similarly, the job of a news article isn't to inform you about anything, but to keep you scrolling until the end, so that you may see more ads along the way. That's why you don't see the Inverted Pyramid anymore[0].
OT but classic HN not to read the article and only comment on the headline. I feel this part of the guidelines makes it hard to address, when I really just want to say "RTFA before commenting" to some ridiculous comments that would make no sense if the poster had actually read the article.
> Please don't comment on whether someone read an article.
I read the article before coming to read the HN response to it. I haven't read beyond your top-of-the-thread comment.
The article resonated deeply with me, because I know just how the author feels. I, too, have developed a software product that attempts to address a key failing in one of the (more under-utilized) DOM elements we have at our disposal when building websites. I can see the problem, and some of the solutions - but other developers are simply not interested. I've marketed the product to the best of my abilities, written blog posts about why I think this is an important issue. I've even tried to engage with people supposedly interested in overcoming the failing to help me make the product even better ... <crickets-chirping> ... nothing.
The harsh truth is you can't market a solution to a problem that nobody else believes is a problem in the first place.
I've posted links to my product on a number of occasions to HN, both as 'Show HN' threads and in comments. Engagement has been minimal. My most upvoted comment on HN was a contribution to a thread about octopuses. Maybe HN is trying to tell me that I would be better off developing a standup comedy routine? Whatever. Unlike the author and his company, I'll not be pivoting away from my product in the near future: I just need to find new ways to shove its existence into people's faces.
> I, too, have developed a software product that attempts to address a key failing in one of the (more under-utilized) DOM elements we have at our disposal when building websites
Haven't had a chance to look at the code yet, but how did you address responsiveness? It took us a long time when writing chart.js to get that working well on with different browsers, devices, and screens (high resolution screens require extra code)
First: chart.js[1] is an excellent library. If people need to add chart infographics to their website I strongly recommend they use a dedicated charting tool (like chart.js) rather than my library.
Like you, I've had to do a lot of coding and experimentation to get responsiveness working the way I think it should work. Much of it runs off the idea of drawing everything to a hidden canvas and then copying that canvas's contents over to the displayed canvas as the last step in the display cycle. I tried to mimic this functionality on the CSS object-fit property[2]. If you're interested in the code, you can find it here - https://scrawl-v8.rikweb.org.uk/docs/source/factory/cell.htm...
The other thing I've done is to introduce relative positioning for drawing stuff on the canvas. The native Canvas API drawing functions expects coordinates etc to be in absolute value pixels; my library allows coders to define positions and dimensions in String percentage values which will update (via dirty flags) each time a change in the canvas dimensions is detected.
Caveat: my library has not been tested (as far as I'm aware) across a wide variety of browsers and devices. I expect there will be plenty of improvements to be made once that happens.
Dealing with Canvas is painful. I recently ran into a weird image distortion issue on Samsung Internet Browser 12 (I guess it's based on the Chrome engine) when drawing a video frame to a canvas context using `drawImage`.
Since you've made Canvas your focus, I'm curious if you've seen this or have any ideas. Here are a couple reports I found online.
This one shows exactly what I see (note: this is not my post), and I was able to "fix" it using the technique in the question. I'm not particularly happy with that solution so I'm still working to understand what's going on.
I don't have an answer for you, except to say that getting <video> and <canvas> elements to play nicely with each other across all browsers and devices is pretty much guaranteed to damage your day, week, or even your month.
My Google searching bought me to this posting about Samsung Internet's Video Assistant feature (Nov 2019). My gut feeling is that the Video Assistant is possibly getting in the way of your code executing as expected? https://www.xda-developers.com/samsung-internet-10-2-stable-...
One month is about right when you add it all up. Not fun.
Thanks for the suggestion. I have only found this to be an issues with version 12 and on. I have examples from version 9 & 11 that work as expected (both before and after video assistant was introduced). And I'm able to reproduce the issue with the video assistant turned off.
Of course, none of that is to say it's not related to the video assistant in some way. I just don't have evidence of that yet.
There are a number of excellent libraries ('products' - I use the terms interchangeably) dedicated to making development with the <canvas> element a lot easier; they all have a strong basic use case because coding scenes using the native Canvas API is very low-level, repetitive and easy to get wrong. Some of my favourites include Fabric.js, Konva and Pixi.js.
I’m sensing some attitude issues just reading this, to be completely honest.
If your reaction to your library/product/whatever not taking off on HN is to get on HN and complain about it, you’re probably building whatever it is you’re building for the wrong reasons.
> I can see the problem, and some of the solutions - but other developers are simply not interested.
Developers are constantly marketed all kinds of solutions. You, the library author, have a responsibility to convince developers that the problem you’re working on is legitimate. If that’s not getting across, that’s on you.
> Maybe HN is trying to tell me that I would be better off developing a standup comedy routine?
Why would anyone want to take you or your work seriously after reading something like this?
It's true. The challenge is developing in a way that covers the wide range of human disabilities (e.g. vision to cognitive). WCAG will continue to evolve to try and capture the full range. That range of disabilities is why manual testing with a screen reader and a keyboard is the current best solution for uncovering edge cases where a website, or mobile app, is inaccessible.
But it also doesn't cause the developer enough pain to register as a priority. The market is telling you something: it either isn't painful enough to spend money on, or you're not reaching the right people. IMO, you can sell to developers, but you have better luck selling them something that feels like it gives them a superpower, e.g. React is an easy sell because:
1. Reactive binding burns away a lot of imperative state-changing code
2. Facebook branding implies it is industrial-strength
And even then, React costs them their time to learn, build on, and ship. If it's their company's time, then they're not going to value it the same way.
You have solved the problem of the considerable "extra" effort that web accessibility requires? Less than that, to be honest I'm not interested. If you have, well, extraordinary claims require extraordinary proof. Would you say that you have extraordinary proof?
Reading this back to myself, I think that I sound like an asshole, but it's my honest thought process fwitw.
> You have solved the problem of the considerable "extra" effort that web accessibility requires?
Have I 'solved' web accessibility for the <canvas> element? No. Have I coded up a JS canvas library that has, as one of its central aims, the idea that <canvas> elements can, and should, be made accessible? Yes - that's what I'm attempting to do. It is a work-in-progress; I guarantee that my solutions can be improved on: Rome wasn't built in a day.
> Would you say that you have extraordinary proof?
The results of my efforts to date can be seen on the library's home page. Criticisms and suggestions on how to make things work better are always welcome! https://scrawl-v8.rikweb.org.uk/
Could also be summarized as "pivoting hard is almost certain death" – bleeding-edge tech just changed the number of problems from large N to N+1. You have to basically shift the mindset of an entire company, and everybody was hired with pre-pivot skills in mind.
Easier said than done I know (although I work in a technical capacity in a company that did exactly that - entered a market with tooling/tools that didn't exist, and had to prove the product actually had any value) - but I didn't see the part where they got trial customers, delivered on their value prop, and made them into case studies on how much value they were delivering.
If they were able to for example have a handful of customers who averaged (entirely theoretically) a 7% increase in profits at a cost of 1.5% of their operating profits, it would have been entirely possible for them to be on an upward trajectory.
Sometimes I need to echo things back to understand.
1. Start-up decides to scrap their current, unhappy business to pivot into a totally different area for which they have no long passion.
2. Start-up develops a product for a small, small niche: companies making design systems that also drive product development decisions based on actual, as opposed to requested, client usage. And said development company cannot use log analytics, roll their own, nor existing companies like Teleric.
3. They create a solution to said possible problem, without a planned first customer nor existing application.
I don't think that is really true. Most start-ups fail, whether they build a bleeding edge product or try to compete on an existing market with smaller enhancements. After they fail if it's easy to pick the reason.
Very few start-ups succeed whatever they do. Skype was pretty bleeding edge at the time, the internet speeds wheren't really there at the time. Spotify or Tesla didn't enter a market with real competitors. Before they succeed, it's difficult to say whether they took the correct risk.
Someone has to be the first, chances are just not very good it will be your company.
I had never even heard of Pandora. A quick check seems to suggest that they are America-only, Alexa rank 800, while Spotify is international, rank about 80. As a European I hope I am excused.
Yes, Pandora seems to be older. How intense the competition was when it started I have no clue. I'd say it was bleeding edge in either case, in those days broadband internet was not so widespread, not to mention mobile data.
This reminded me of the early days of launching SnapScan. Firstly, it was about the 4th time we had rebuilt and relaunched a payments app. Then, we launched it for online payments which got absolutely zero traction.
Eventually we went and sat at weekend markets and coffee shops and spoke to customers and merchants one-by-one to explain to them everything about it: why we built it, who we were, how the security worked, where they could find us if we lost their money, how to download a mobile app, how to link a bank card to an app. We manually did this with probably over 1000 customers.
And then we gave them R50 to use it, and for the first year gave merchants the product for free.
This set us up for success. We deeply knew how customers perceived our app and using their phone to pay. We had also deeply educated a small army of people. And we had personal relationships with them, they had literally saved my number on their phone and could call me.
This article was a great reminder of the mental strain that took.
Just want to say this website is what I think a modern website should look like!
Loads in under 1 second, has a simple but very cool design, no needlessly heavy JS framework in sight, due to the images it's a bit heavy at around 2.7MB, but still pretty good.
It's interesting that the author indicates other companies like AirTable and Notion aren't doing anything completely new, merely expanding on existing ideas.
It seems to me that their product was essentially "usage metrics, but for component systems". Somewhat novel, sure, but I'd hardly call this _completely new_ as compared to aforementioned products.
For https://expose.sh I use TypeScript for the back end and the client so I get the benefit of one language for the whole service. TypeScript has been around for a few years but it is still pretty new compared to say Java.
By using Docker for the dev environment of the PHP ecommerce platform, it saved me from having to build one myself.
195 comments
[ 3.4 ms ] story [ 111 ms ] threadWondering how you have/are managing to do it?
> they rather take a pay-cut to work with the stuff they know and are good at.
The question is, are your employees aware of this?
but yeah my mindset always was being the jack of all trades, which is very good for small startups and not a good mindset for corporations which I avoid..
I also think the "sense of ownership" part that comes with making decisions like that is important. With a startup, it's beneficial if contributors feel they're able to fix problems they see proactively.
But, yes, I don't want to work with hype-driven or resume-driven coworkers. Yes, I want the choices to be pragmatic and well-considered.
The kube API (the pod/deployment/service/ingress structure) is where the magic is, imho. Sure you could just make an EC2 instance, and swap in your Rails, and redirect the ALB and fix your domain CNAME, but whatever man, you can do like 4 of those things in an instant in Kube.
Yeah, definitely Heroku over k8s for idea validation.
I think there's definitely room in the k8s-based space for slightly past that, though.
I use the Jojoma framework to abstract away all that Kube stuff. It's trivial to use through Baobab, especially if you use the Wazabi framework-as-a-service framework (which you should). All you have is to deploy the proclets through a DMVC and it's all automagic.
I iterate through 17 startup ideas a day using that setup.
FWIW I actually really quite liked RethinkDB.
- If your business doesn't rely on new technology, then avoid bleeding edge tech (examples: you retail co-working space, rent apartments, do food/grocery delivery, etc.)
- If your business model does rely on new technology (examples: airlines in the early 20th century, railroads in the early days of the steam engine, e-commerce in the early 2000s) then you have to work out a way to deliver on bleeding-edge technology. That's where your competitive advantage lies and that's where the nice margins are.
Though even in the latter scenario, it's still prudent to narrow the scope of your bleeding-edge tech as much as possible (e.g. if you're doing a cryptocurrency app, you probably shouldn't be trying to make your own NoSQL database at the same time).
Nonsense, the database is the back up plan so you can pivot to a DB company if your main thing doesn't work out.
Even the steam engine people had to rely on known standard parts like screws and bolts and known planing or manufacturing procedures that they didn't invent. Only because they knew which forces a bolt would withstand and learned from (at times catastrophic) failure they were able to even have a bleeding edge.
Also, if your business model does rely on new bleeding edge tech, avoid all other bleeding edge tech. Pick one thing that nobody else can do, and do that. Don't try and create everything at once unless you have ridiculously deep pockets.
I used to work for an organization that has a team of mostly Java developers. They want to move to Python, in part because the big guys (Google, Netflix, and NASA as cited by them) did it too.
They are just building a run of the mill web app, but they are changing the entire stack for a new project that next to nobody on the team knows well.
As a baseline, it's relatively easy to make an autonomous aircraft that follows GPS waypoints using an atmega328 and have CPU cycles to spare, even using software floating point math everywhere. All the open source drone firmwares recently dropped support for orders of magnitude more powerful cortex-m3 flight controllers, though, and are encouraging folk to migrate to cortex-m7 based controllers. That's crazy! Software tends to expand to fill up any available volume over time...
I really hope the reason isn't "so we could run the mainline linux kernel" or "because we needed a RTOS" or something similarly bloated.
Why implement quicksort when bubble sort will give you the result you need just as "instantly" and be easier to verify?
Why bother procedurally iterating line by line through a 1GB of text in python, when you can call f.read().split("\n") inside a list comprehension and probably have it run just as fast because you have a 64-bit 4Ghz superscalered mmxzomg Inteliapple CPU and 32GB of RAM.
Often times, the bloat is an intentional tradeoff to make something else better. More accurate code, more readable code, more configurable code, etc. Other times, it really is just bloated, more terrible code; even that has some value, if it meant that someone was able to contribute a useful feature that they wouldn't have otherwise been able to due to lack of skill or domain specific knowledge.
I think I am thinking more specifically about the flight feedback example compared to what you are describing, but I'm definitely all for using cheap powerful ARM chips in place of obsolete stuff. I'm just hoping that most of that spare computing power was used for something cool and not just spinning the wheels.
Much better to update the hardware when you have a chance than to stick with an obsolete part until the rug is pulled from under you and it's EOL'd.
Most of the time, more power also brings more complexity. Cortex-M7 mcus, for example, typically can't reach their max CPU throughput without turning on instruction and data caches or "Tightly Coupled Memory". Data caching opens up a whole can of worms when interacting with memory mapped peripherals. Some MCUs with data caches have peripherals glued to them that are fundamentally incompatible with caching, leading to having to use indirect tricks like using DMA transfers to interact with them. TCM partitions your available memory space, leading to arbitrarily complex application specific linker scripts.
Newer chips are sometimes less capable on different axes. It's easier to use a 5V chip to interact with a 5V circuit, rather than a "better" MCU that is only 3.3v tolerant and requires a filtered 1.8V power rail for its internal circuitry. More complex CPUs generally have less predictable and potentially slower interrupt timing too.
Spinning new hardware also isn't cheap like spinning new software is, both in terms of dollars and in externalities. A popular community maintained firmware dropping support for an old but popular hardware generation that's become burdensome to maintain due to incremental feature bloat may be perfectly justified by the volunteer developers, but it does effectively turn that old hardware into e-waste. A company producing widgets with embedded components in it might want to defer the risk and schedule hit of switching to a new MCU architecture for as long as possible, in order to balance overall company goals and limited engineering resources. Justifying engineer months of work "because it's better and everyone will like working on it more!" is a lot tougher to prioritize than "because we only have enough stock left for 6 months and then we're scraping ebay".
I definitely never expect to use a PIC or Atmel chip though, wow those were terrible. I guess small quantities really hurt.
Other than that they are faster, cheaper, and have more RAM.
Definitely only do one of these at a time, tho :)
All of the comments for some reason are about not using latest-nosql-db-from-producthunt in prod.
I think Discord is one good example of this sort of trade-off. Single, pretty standard type of app that improves on its predecessors, with some bleeding-edge engineering: https://blog.discord.com/why-discord-is-switching-from-go-to...
>Discord has never been afraid of embracing new technologies that look promising. For example, we were early adopters of Elixir, React, React Native, and Scylla. If a piece of technology is promising and gives us an advantage, we do not mind dealing with the inherent difficulties and instability of the bleeding edge. This is one of the ways we’ve quickly reached 250+ million users with less than 50 engineers.
>Embracing the new async features in Rust nightly is another example of our willingness to embrace new, promising technology. As an engineering team, we decided it was worth using nightly Rust and we committed to running on nightly until async was fully supported on stable. Together we dealt with any problems that arose and at this point Rust stable supports asynchronous Rust. The bet paid off.
(They also mention how they're careful to replace decoupled components incrementally, and only where it addresses a real need, rather than for the fun of it.)
I wonder if not speeding is enough to give police officers a reason to make a drugs search in some places.
Czech here, I was stopped by the police once in the night on an empty 4-lane road doing exactly the speed limit. They breathalyzed me, looked at the zero and one of them said: "you know, when someone keeps the limit at midnight on this stretch of the road, they are usually drunk".
* It's users were consequently having to use multiple platforms, with teamspeak or vent or mumble for voice chat and Skype or Facebook for persistent text chat. This was inconvenient adding everyone twice.
* It's hard to explain how much it helped for the "bringing a random into your gaming group" scenario. You could just drop a link into the games text chat and people could join for the night and you didn't have to worry about if they had teamspeak or mumble or whatever installed.
* Teamspeak's free tier had a limit of like 10 users known to the server. Discord did not.
* Slack wasn't a competitor for Discord's initial market. Having to sign up for each instance was a deal-breaker. Discord originally allowed guest accounts, and I think it still does. Also the overhead to creating/managing a new server and adding people is really low comparatively.
* Discord doesn't really compete with Twitch much? People stream to their friends sure, and I have known people who had unlisted twitch channels for like jackbox in the past but that's a relatively late addition, and twitch is much more interested in the big streamers than the long tail anyway.
Obviously discord have significantly expanded their market a few times from FFXIV raiders to all mmo players to all gamers to everyone, but they started with clear problems to fix and fixed them well
It's interesting how they started out focused on gaming and have since moved away from it. I discovered a new Discord competitor, Guilded.gg, that sprouted up with marketing claiming Discord has abandoned gamers and they're going to recapture them.
It just goes to show that you never know which direction it's going to truly move and you have to be able to pivot. But having a core initial user group that you solve a problem for is key, and having a working product is key as well.
It feels like I'm moving a brick around. Was going to return it, but now I'm saving it for a protest.
I thought it was still bumble bee tuna.
I wish they covered the mice in solar panels like the solar-powered wireless keyboard, or harvested kinetic energy though -- that keyboard is another great Logitech hit if your workspace is near a window -- you never have to charge it.
Furthermore, there’s plenty of dolphin safe tuna out there, which does mean something as designations go:
http://savedolphins.eii.org/news/entry/what-does-dolphin-saf...
Finally, it's one of the most dangerous jobs, and often exploitative.
From what I can see, the paradigm of component-based design has been growing in popularity since the tools like Figma have been improving rapidly.
In that case, it's a product for a niche and growing audience. I think the website hits some of the main points pretty well.
This is what should be at the top of the the main page of their website if it's correct. Because endlessly scrolling hoping to find out what problem a product solves isn't a good way to sell a product.
Glad someone took the time to read the damn article lol
Interesting reading by the way.
“But guess what, they had no idea how to use our tool or integrate it within their workflow. And to be honest, nor did we. Adoption was bleak and feedback was dry—silence in startups is not golden.”
Making something nobody wants is a classic startup mistake. I resolved not to make it again and read a great deal about market validation and building products.
I have one recommendation for those reading this thread: Steve Blank's "Four Steps to the Epiphany". It contrasts Product Development (focusing on a product with no customers) vs Customer Development (focusing on customer problems and building software around those). Honestly you don't even need the whole book, there's a PDF with the first couple chapters floating around [1]. I had a bunch of "holy shit, that's exactly what I did wrong" moments while reading it.
Eric Ries' "Lean Startup" is also an excellent book on this topic.
[1] http://web.stanford.edu/group/e145/cgi-bin/winter/drupal/upl...
As for building a solution to "a problem that the intended users don’t understand that they have", I'll agree that this may not be a good thing for a startup to do - but when I see how basic research is being defunded and drowned in red tape, and people saying that startups are the new, distributed R&D departments, I feel the middle has fallen out. When startups do a greedy gradient descent, and academia struggles doing science, who's going to work on solving problems that require solutions one or two steps beyond what the intended audience can understand? FLOSS community? What about outside software?
First off, they hijack your scroll wheel and present you with some Apple-esque website that is very slow and doesn't work properly. > "Remote, component-driven, and obsessed with speed." I think not.
Second, they show zero screenshots of the service or what the benefits are to using it. > "Handoff reimagined." Yea, okay... Nice slogan, now show me before I move on!
No wonder they're having issues convincing new customers. They think they're selling a space ship when really they only need to improve their website copy.
[0] https://www.contrast.app/
"As designers and engineers, we knew of a rather niche problem: if your company has a design system, it's practically impossible to know the adoption rate of those components in your product."
Yeah, and I've never met anyone who cared to be honest. And if you do care, your answer is usually a quick "git grep" away.
It only creates a confusion when most people don't bother reading articles when the headline is strong enough to inflict a response. It has become a tool to say something and deny saying it.
The article serves two purposes. It's primary job is to be a scaffolding for delivering advertisements to the reader. The secondary purpose is to be a word soup that makes the article appear in search results related to some popular topic.
That's it. Many people don't realize that the job of a headline is not to be truthful, accurate, or even sensible. It only has one job to do: make you click through, so that ads can be shown to you. Similarly, the job of a news article isn't to inform you about anything, but to keep you scrolling until the end, so that you may see more ads along the way. That's why you don't see the Inverted Pyramid anymore[0].
That's modern journalism in a nutshell.
--
[0] - https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism)
> Please don't comment on whether someone read an article.
https://news.ycombinator.com/newsguidelines.html
The article resonated deeply with me, because I know just how the author feels. I, too, have developed a software product that attempts to address a key failing in one of the (more under-utilized) DOM elements we have at our disposal when building websites. I can see the problem, and some of the solutions - but other developers are simply not interested. I've marketed the product to the best of my abilities, written blog posts about why I think this is an important issue. I've even tried to engage with people supposedly interested in overcoming the failing to help me make the product even better ... <crickets-chirping> ... nothing.
The harsh truth is you can't market a solution to a problem that nobody else believes is a problem in the first place.
I've posted links to my product on a number of occasions to HN, both as 'Show HN' threads and in comments. Engagement has been minimal. My most upvoted comment on HN was a contribution to a thread about octopuses. Maybe HN is trying to tell me that I would be better off developing a standup comedy routine? Whatever. Unlike the author and his company, I'll not be pivoting away from my product in the near future: I just need to find new ways to shove its existence into people's faces.
Link?
Like you, I've had to do a lot of coding and experimentation to get responsiveness working the way I think it should work. Much of it runs off the idea of drawing everything to a hidden canvas and then copying that canvas's contents over to the displayed canvas as the last step in the display cycle. I tried to mimic this functionality on the CSS object-fit property[2]. If you're interested in the code, you can find it here - https://scrawl-v8.rikweb.org.uk/docs/source/factory/cell.htm...
The other thing I've done is to introduce relative positioning for drawing stuff on the canvas. The native Canvas API drawing functions expects coordinates etc to be in absolute value pixels; my library allows coders to define positions and dimensions in String percentage values which will update (via dirty flags) each time a change in the canvas dimensions is detected.
Caveat: my library has not been tested (as far as I'm aware) across a wide variety of browsers and devices. I expect there will be plenty of improvements to be made once that happens.
[1] - https://github.com/chartjs/Chart.js
[2] - https://developer.mozilla.org/en-US/docs/Web/CSS/object-fit
Since you've made Canvas your focus, I'm curious if you've seen this or have any ideas. Here are a couple reports I found online.
This one shows exactly what I see (note: this is not my post), and I was able to "fix" it using the technique in the question. I'm not particularly happy with that solution so I'm still working to understand what's going on.
https://stackoverflow.com/questions/63911732/javascript-canv...
Here's another report that seems related, although there's no mention of interaction with the video element.
https://forum.playcanvas.com/t/samsung-internet-browser-canv...
My Google searching bought me to this posting about Samsung Internet's Video Assistant feature (Nov 2019). My gut feeling is that the Video Assistant is possibly getting in the way of your code executing as expected? https://www.xda-developers.com/samsung-internet-10-2-stable-...
Thanks for the suggestion. I have only found this to be an issues with version 12 and on. I have examples from version 9 & 11 that work as expected (both before and after video assistant was introduced). And I'm able to reproduce the issue with the video assistant turned off.
Of course, none of that is to say it's not related to the video assistant in some way. I just don't have evidence of that yet.
I'm not sure you have a 'product' you just have a library.
If your reaction to your library/product/whatever not taking off on HN is to get on HN and complain about it, you’re probably building whatever it is you’re building for the wrong reasons.
> I can see the problem, and some of the solutions - but other developers are simply not interested.
Developers are constantly marketed all kinds of solutions. You, the library author, have a responsibility to convince developers that the problem you’re working on is legitimate. If that’s not getting across, that’s on you.
> Maybe HN is trying to tell me that I would be better off developing a standup comedy routine?
Why would anyone want to take you or your work seriously after reading something like this?
It's not necessarily if people care but what they care more.
But it also doesn't cause the developer enough pain to register as a priority. The market is telling you something: it either isn't painful enough to spend money on, or you're not reaching the right people. IMO, you can sell to developers, but you have better luck selling them something that feels like it gives them a superpower, e.g. React is an easy sell because:
1. Reactive binding burns away a lot of imperative state-changing code
2. Facebook branding implies it is industrial-strength
And even then, React costs them their time to learn, build on, and ship. If it's their company's time, then they're not going to value it the same way.
Reading this back to myself, I think that I sound like an asshole, but it's my honest thought process fwitw.
Have I 'solved' web accessibility for the <canvas> element? No. Have I coded up a JS canvas library that has, as one of its central aims, the idea that <canvas> elements can, and should, be made accessible? Yes - that's what I'm attempting to do. It is a work-in-progress; I guarantee that my solutions can be improved on: Rome wasn't built in a day.
> Would you say that you have extraordinary proof?
The results of my efforts to date can be seen on the library's home page. Criticisms and suggestions on how to make things work better are always welcome! https://scrawl-v8.rikweb.org.uk/
It does make me wonder, given the deceptive nature of the title and obviously emotive topic of whether devs should use bleeding-edge tech...
If they were able to for example have a handful of customers who averaged (entirely theoretically) a 7% increase in profits at a cost of 1.5% of their operating profits, it would have been entirely possible for them to be on an upward trajectory.
1. Start-up decides to scrap their current, unhappy business to pivot into a totally different area for which they have no long passion.
2. Start-up develops a product for a small, small niche: companies making design systems that also drive product development decisions based on actual, as opposed to requested, client usage. And said development company cannot use log analytics, roll their own, nor existing companies like Teleric.
3. They create a solution to said possible problem, without a planned first customer nor existing application.
4. They are surprised when sales is difficult.
I still don't understand.
Very few start-ups succeed whatever they do. Skype was pretty bleeding edge at the time, the internet speeds wheren't really there at the time. Spotify or Tesla didn't enter a market with real competitors. Before they succeed, it's difficult to say whether they took the correct risk.
Someone has to be the first, chances are just not very good it will be your company.
Yes, Pandora seems to be older. How intense the competition was when it started I have no clue. I'd say it was bleeding edge in either case, in those days broadband internet was not so widespread, not to mention mobile data.
Eventually we went and sat at weekend markets and coffee shops and spoke to customers and merchants one-by-one to explain to them everything about it: why we built it, who we were, how the security worked, where they could find us if we lost their money, how to download a mobile app, how to link a bank card to an app. We manually did this with probably over 1000 customers.
And then we gave them R50 to use it, and for the first year gave merchants the product for free.
This set us up for success. We deeply knew how customers perceived our app and using their phone to pay. We had also deeply educated a small army of people. And we had personal relationships with them, they had literally saved my number on their phone and could call me.
This article was a great reminder of the mental strain that took.
If not,
Loads in under 1 second, has a simple but very cool design, no needlessly heavy JS framework in sight, due to the images it's a bit heavy at around 2.7MB, but still pretty good.
It seems to me that their product was essentially "usage metrics, but for component systems". Somewhat novel, sure, but I'd hardly call this _completely new_ as compared to aforementioned products.
For https://expose.sh I use TypeScript for the back end and the client so I get the benefit of one language for the whole service. TypeScript has been around for a few years but it is still pretty new compared to say Java.
By using Docker for the dev environment of the PHP ecommerce platform, it saved me from having to build one myself.