Bleeding-edge tech will kill your startup
contrast.app
contrast.app
This article has nothing to do with bleeding-edge tech. It's about launching a product around which zero validation work has been done.
The quote above is the entire description of the alleged "bleeding-edge tech." I still don't know what the problem is. "Design system" is vague enough to me at least to be meaningless. There's a screenshot that looks like web analytics.
Web analytics have been done to death. This isn't bleeding-edge tech. It's me-too products desperately fighting for market share by going ever deeper. Big difference.
You've got to be an excellent communicator to play this game. Given the mismatched title and fluff in the article, I can see why the team had a hard time connecting with prospective customers.
> prospects didn't know [...] the problem we were solving
If "prospects" don't know what problem you're solving, 99% of the time that means they don't have the problem your product solves. And if that's true, they're not actually a prospect. Seems like a classic case of being a solution looking for a problem.
Also the author's nonsensical "circle of death" reminds me of the "Conjoined Triangles of Success" from Silicon Valley[1]. Except Silicon Valley is a parody, and I don't think this article is meant to be.
This is in contrast to the "non-systematic" approach, which is to have designers use apps like Photoshop to copy-paste design elements and then have developers eye-ball and eye-drop that into code. You may up with lots of redundant definitions for essentially the same visual intent, especially with larger teams.
Most products start out with the non-systematic approach and then may later attempt a switch to a design system. Presumably, this is where this product could help you validate your progress. Whether integration of such a product is a valuable addition to your workflow or a distraction is up for debate.
You also need adoption across all the teams in your org to reap most of the benefits.
My wife is the UX Designer in the family, so I can't say more than that, though
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.
"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.
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 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.
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.
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.
Yes, it's hard to sell something people don't understand, but that's marketing. So you figure out their needs and the needs that your product fills and you focus on that.
Pricing? You look at the cost of not using your product and go from there. Are you automating a human task that a single person does an hour a day? Start with that. Is your product reducing failures? Find out what those failures are costing. Start with that. Are you competing with a different product? Undercut or make sure your product adds more value.
Product? Get a couple of 'beta testers' and interact with them, often. Find out what they want for them to buy the product and focus on stuff you and other beta testers agree with.
Mental? Yeah, it is. running a startup isn't easy and nobody said it was. It took us over a year to proof that we could to what we wanted and nearly another to get to something we could sell. I got burnt out and ended up leaving.
Now, though, they started hiring and are getting more well-known in the PA community. Even PA firms are starting to lose customers to the tech I designed and built. It was never easy, it was very hard, but it wasn't because of the tech, it was because starting a business is bloody hard.
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.
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.
> Market Type changes how you evaluate customer needs, customer adoption rate, how the customer understands his needs and how you should position the product to the customer. Market Type also affects the market size as well as how you launch the product into the market. [0]
Incorrectly identifying market type can certainly kill your company, or make the process of working on it really painful.
However, I do think building a new market is a different kind of bet. Much more uncertain, much riskier, and larger upside potential (but I think that upside is harder to capture, especially if you're early in the space).
FWIW, I do like the pivot. We're using 1:1 component mapping between our designs in Figma and React front-end, it's something I can imagine using.
[0] https://steveblank.com/2009/09/10/customer-development-manif...
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.
What is astonishing is that after the fact someone is still trying to extract value from it by positioning obvious learnings as insights.
How is that bleeding-edge? It's just "lint for design systems". What happened probably is that the number of people who actually use a "design system" is fairly small. And among them, those who understand what linting is are possibly rare...
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.
Uhmm, think I spotted their problem right there. If they (as the creators) couldn't figure out how it would fit in to a prospective customers' workflow then that is both an incredibly difficult proposition to sell and also an incredible waste of time for the customers that did decide to try it out. Appologies if someone has already stated that (read the article , skimmed the commments)
No shame in trying and failing at a cool idea, but I’m worried the author is taking the wrong lesson. It’s not about “bleeding edge” or being too early, it’s about target market and utility. No small company would ever need this, so you’re automatically moving into the enterprise space. However in the enterprise space you need to solve problems that decision-makers care about. That means going into sales mode day 1 and getting immediate feedback in order to land that first sale. You need a demo more than a product, and you need to listen more than you talk.
Regardless, "Bleeding-edge tech will kill your startup" is not a good title for the article. The actual article title (maybe it was updated) is a bit better- "Bleeding edge tech means you'll bleed to death". But most people here are miffed that neither title makes it obvious that the article is about selling 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.
> [this is your brain on drugs] "Firstly, makes no sense seeing everyone loves fried eggs. Secondly, this is how my brain looked when trying to start a "bleeding edge" tech company."
but... you undermine your own point! you just said everybody loves fried eggs, so shouldn't your brain looking like that with bleeding edge tech be a good thing? you just said it's a good thing.
I'm pointing it out because it's two of my pet peeves, (1) people attack the analogy, screaming "fallacy reeeee" when they disagree with the overarching point, then they embrace the analogy when they agree; it shouldn't be that way. The analogy is always a good thing, it's a metaphorical tool for conveying a point of understanding and it's not an argument in itself so it can't be a fallacy; and (2) people, young people especially, reflexively feel the need to endorse drug use and more broadly, decry any puritanical notion, to the extent of willing suspension of disbelief that porn, drugs, gambling, and addictions to dopamine might actually not be all that beneficial a use of your time. (I realize that's a complicated sentence; I'm trying to "weed out" the stoners)
We would ask ourselves: "Could process A be replaced by WhatsApp in this or that way?"
If the answer is Yes, then we would advise stakeholders to rethink that process or functionality to make it unchallengeable by the IM in the short run.
They developed a tool without developing working out how it would be used. Is this a problem of bleeding tech in itself, or more of a problem of (product/service) comprehensive development methodology?
Why would having design consistency prevent you from understanding whether users are using a given feature?
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.
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.
Wondering 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.
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.
oh god
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.
If not,
FWIW I actually really quite liked RethinkDB.
*
A) They say they failed because they had a bleeding edge product
IN Reality: they are talking more about Product Market Fit not being there/not being properly tested
B) They say that selling such a product is difficult, getting companies to implement it is difficult, and that the mental game is more difficult
In Reality: They seem to not fully understand their own product, what their customers' needs are, and how their product matches those needs
A few other points, with some overlap with the above
Firstly, that product they discuss is not very bleeding edge. It's basically Analytics. It's not like they were trying to sell Virtualization or Nuclear Fusion Reactors
It's Analytics/What Gets Measured Gets Managed/Pareto Principle
-> We should build a tool that tells you the adoption rate of every component in your design system—across your product
How is that bleeding edge?
*
Secondly, Winter 2018 to Summer 2020
That's 1.5 years
Is that really time to tell if a product is a hit or not?
Look at all the companies that are going IPO now. They are between 5 to 20 years of existence before IPO
Outliers like Amazon and Facebook have really messed up lots of people's perceptions of what building a company should be like
They think everything is going to come together in one or two years
Thirdly, all their problems (sales is hard; companies adopting product is hard; mental game is hard) is basically
A) Your product doesn't have Product Market Fit. If there is a good fit then NEW makes it sell faster because no one else has it
B) Your mental game is weak. If you are going to give time to a product (even a not that significant 1.5 years of your life) you must make sure you give it your best shot
C) It seems all your issues rise from you thinking SOMEONE ELSE is going to do stuff for you
You have to sell
You have to get the company to adopt the product
You have to keep yourself focused and positive
*
Do you really understand what problem that product solves?
Does your customer want that problem solved?
People will buy what they understand.
Who can blame them? Your real bleeding edge tech company is outnumbered by snake oil companies 1:1000.
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.
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.