256DEV's comments

Some newer TLDs like .dev or .app have a tiered pricing structure. So it becomes less economically feasible to squat the best names. They also released them in stages when the TLD first went live.

This guy (https://medium.com/@amd_2793/my-million-dollar-domain-hobby-...) actually used Google's rankings of domain value from .app to then squat domains on two other flat priced TLDs - io and ai!

Interesting question! Well no one has complained so far, but I should definitely run them all through Google Translate to see. I could see this happening quite easily.

The one issue I did have was buying a domain on Namecheap auctions only to find it had been used very aggressively by spammers before going to auction. It made me think of the recent top HN post about how you could push a suspect domain to someone within a registrar and then implicate them without their knowledge. The Namecheap auction system happily let me buy the domain, but then as soon as it was in my account it got suspended and I got various emails from their security team about how many blocklists it was on and how I'd have to submit extensive documentation to get it unsuspended etc. Thankfully the support was helpful and now I check domains more thoroughly before I buy them...

Well well, I did not know that.. Thanks for expanding my vocab! Maybe a better example would have been the similar Zuora!

One of my hobbies is the diametric opposite of this approach, I enjoy trawling domain auctions for short .coms that don't include any dictionary words but still sound fun. I love names like Quora that are meaningless but still somehow feel like they should be a real word! I believe the academic category for these is "lexical gap". During the pandemic I got a little too much into it and so now I'm actually busy working on a site to list them for sale - https://wuzmo.com - the plan is to make it essentially a cheap brandbucket.

I can confirm the VAT handling works really well and I even have customers thank me for supporting VAT properly. Particularly EU customers that have higher expectations for this compliance. My original reason for starting to use Paddle for my SaaS was actually just because Stripe wasn't available in my country and I'd prefer anything to PayPal/2Checkout, but now after approx. 18 months I don't think I'd switch if Stripe launched here tomorrow.

They've also added an "Invoicing" system now so we can also be as easily VAT compliant for enterprise deals that will only pay by wire.

Impressive project, nice work! I'd use the `outdated` command but even just the basic listing of installed packages across all managers looks useful to me.

It's a move in the right direction but I can't help but feel that this is an example of a massive corporation getting ahead of regulation with a watered down version of right-to-repair than Apple suddenly having a genuine change of heart...

That said, my sincere hope is that this move doesn't dampen enthusiasm amongst people considering switching from Macbooks to Framework laptops. We desperately need a computer manufacturer that puts repairability at the core of their design process and Framework has made such a high quality start that it even with their first attempt it doesn't feel like a compromise!

If you care about really owning your device and being able to repair it take a close look at the caveats Apple may include in the actual details of this programme versus with Framework.

Basically I understand the idea of serverless in this context as abstracting away everything related to managing & maintaining the database - i.e. anything like VMs, containers, OS, DB processes etc.

So you can set up a PlanetScale MySQL DB and use it just like a normal instance of MySQL, but also keep adding data from one small set of records all the way up until you have gigantic petabyte volumes of data without having to do anything beyond sending the data through your MySQL connector.

In theory it should just keep working in a performant way from 100 user records for your new startup to the scale of running parts of Slack. No choosing bigger and bigger AWS RDS instances as you scale, no need for autoscale strategies in case of traffic surges or worrying about replicas for perf etc. etc.

As someone who is honestly quite resistant to parts of the serverless paradigm this offering actually appeals to me. I prefer running my own fleet of VMs and traditional PHP/Nginx type stack but have already moved to AWS RDS to abstract away some of the replication complexity required to achieve high availability DB with minimum hassle. This seems like the logical next step and despite being allergic to kind of hype you mention finding this is something I'd definitely try out before moving other parts of my infrastructure onto anything like Lambda.

I hate to be the stereotype of skeptical HN reader but I think this headline oversells the article.

Specifically for me it doesn't speak at all to the differences between starting a SaaS like this as a team of founders versus as a solo founder. As a committed solo founder all I can say is that choosing solo founding is not something to be undertaken lightly!

My startup CV is now roughly an equal length of being on a team of 4 founders and the current solo founder situation so I see the differences all the time. There are a lot of positives to both options but to write an article like this and not blend an awareness of the trade-offs between the two makes it much less interesting.

I've really struggled with being a solo founder despite it being a strong preference and learning to face every aspect of the running the business with a very conscious awareness that you're +1 in certain things and -1 in others is the only way I've found to make it work.

The idea you choose is a big part of this. I've seen thinking about your idea & solo founding preference described on twitter by @warikoo like this:

2x2 matrix

X-axis: Do you have the core skill reqd for the startup? Y-axis: Are you a control freak?

Y,Y: DON'T have a cofounder

Y,N: Could get one, but with complementary skills

N,Y: Hire people, might make them cofounders later

N,N: You have to have one!

We registered this domain in 2010 back when there was actually something called the "exact match bonus" in SEO. Basically if your domain exactly matched the searched keywords Google just automatically gave your site a massive boost in that SERP!

I can see why they did this since there were only a few TLD's back then compared to now and thus owning the .com for a specific keyword was a legitimate signal. I can't remember exactly when this got deprecated as a ranking factor but it was very useful for the first few years!

Over the years I've accumulated the domains of failed competitors that had more punchy names and toyed with the idea of rebranding but don't think it's worth it. The SEO risk of a rebrand is substantial concern.

Thanks - I really appreciate that! On one hand it is partly this, the uptime/reliability/LTS endpoints have been the focus of many years of work.

However, that said, I think in the majority of the actual cases I'm describing above the cause is more a combination of 1.) the surprising percentage of tech companies that appear to be in a state of continual organizational dysfunction and 2.) how API's are inherently a background type of thing like lloydatkinson wrote!

In about 1 in 10 cases I'd also say the cause is actually because of merger/acquisition - which is just always a complex and organizationally challenging process.

As someone who runs a currency data API [1] I can confirm this is strongly the case - even to the point where relatively often I get messages to the effect of "we believe our company uses your service - how do we access it and can we use your logs to help us identify where in our infrastructure requests are being sent from...".

Users from clearly legitimate businesses sometimes sign up, start the billing and then just disappear. No response to emails, support tickets etc. I'm often tracking down billing teams 18 months later trying to convince them they really do use our API, and that if I can't get them to renew their billing details I'll have to eventually disable their access due to non-payment and then their infrastructure will no longer have up-to-date exchange rates! In these situations I sometimes disable access for 24 hours and then re-enable it to see if this drums up a dev I can speak to. It's quite a process but I've won some "customers for life" by saving them from downtime they would have had if I just cut them off.

[1] https://www.exchangerate-api.com

Considering how big Apple is already ($80 billion per QUARTER!) the idea that they could at some point still decide to add a search engine and the associated revenues is amazing to me. It obviously wouldn't be a 1-to-1 switch with Google traffic coming from Apple devices but if they seriously attempted it I don't see how it wouldn't be a very substantial business very quickly.

Presumably this payment is based on Google's evaluation of the search ad value attributed to Apple devices but only $3.75 billion per quarter still seems low for how much iPhone search traffic there must be? Especially considering the relatively lower level of iPhone ad blocking vs. desktop I see anecdotally in my non-tech friends. I imagine though that both companies send in fairly deadly teams of apex negotiators for a deal like this so it must be close to representing the true economic value of the tie-up...

This is a great initiative. Interestingly, manual washing machines like this were briefly an incredibly hot commodity in even wealthy suburbs in my home city Cape Town, SA during the extreme drought and water shortages we had in 2017/2018 [1].

They used substantially less water than a traditional Samsung or LG washer and actually worked pretty well. Considering the draconian water rations that had to be put in place people were very keen to speed up washing while still very strictly controlling water use. The local brand that people used was called Sputnik [2]. Now that the drought has broken people often talk about how crazy in retrospect our water usage was before and I even know a few who actually still use these washers because of the efficiency. That said - most folks have gone back to machines now that the water situation is stabilised...

[1] https://en.wikipedia.org/wiki/Cape_Town_water_crisis

[2] https://www.sputnikwashingmachine.co.za

I've actually just gone through the process of integrating my currency API [1] with Micro. I really liked the idea for this service and actually just emailed them asking your exact question! The process was smooth and I was impressed by their clear communication and very responsive development work.

I've been a user of RapidAPI as both an API publisher & consumer and I think I prefer this Micro model instead - API curation, standardized docs etc. etc. RapidAPI can feel like a bit of a free for all and even though it's technically one entity proxying everything it's often felt to me like more of a list of random services than something cohesive. I can definitely see why Micro is describing their service as a sort of AWS of useful APIs.

[1] https://www.exchangerate-api.com

This is definitely a good point. I wonder does anyone know if the Chrome User Experience Report [2] dataset will be used in the upcoming Google Page Experience Update [1]? If it will be included then perhaps this will create pressure for faster whole-site experiences. Basically if your landing pages are fast but your actual SaaS dashboard is slow then this will be reported back to Google by Chrome users - and then potentially affect your ranking.

For those who aren't familiar with Chrome User Experience, Chrome collects website performance data while you browse under certain circumstances (I think you need to be opted into sync) and so Google essentially has detailed RUM data for any web origin with a decent amount of traffic.

[1] https://developers.google.com/search/blog/2020/11/timing-for...

[2] https://developers.google.com/web/tools/chrome-user-experien...

As someone who runs a SaaS[1] I'm always really surprised by how slow many websites are, even those clearly run by well funded teams pushing hard to grow their service.

The following two things seem axiomatic by now to me:

1. It's well established that faster websites convert better in a strongly correlated relationship. From Google/Amazon scale case studies down to smaller ones, the faster your website is the more money you'll make...

2. How fast your website runs is almost entirely within your control, whereas factors like competitor positioning, Google's ranking algorithm, whether your service is mentioned in a viral twitter thread etc. etc. are all not!

Given these it seems spending a few developer hours after each set of site changes to keep things at a perfect 100 PageSpeed score is a very high return investment of time. Especially when some performance improvements affect 100% of prospective buyers, whereas say adding a specific feature might only improve conversion for a small segment of your funnel's first step.

[1] https://www.exchangerate-api.com - you're welcome to judge how fast my site is, I'm always open to suggestions!

RapidAPI. You can consume multiple API's from one account and as a developer it's a good way to monetize an API if there isn't too much competition in your niche. Not sure what you mean by firewalling but RapidAPI does authenticate their requests to your endpoint so as a developer you can do access control in this way.

dmlittle's concern is a valid one and for most other types of API I would definitely agree it's not the right approach.

I still think it's reasonable for my use case but perhaps I should add another auth scheme as an optional alternative for the user who is concerned about their key potentially being caught in logs.

Your point about the documentation is also a good one - I should probably add a specific page just about the authentication approach. Added to the to-do list! Thanks.

Abuse of free APIs is a big issue, I've definitely experienced it a lot and see other API developers in this thread mentioning it.

With my experience though I found that trying to limit signups to prevent abuse caused so much friction for legitimate users that I actually decide to change my strategy to the following:

1. Allow essentially unrestricted access to the free account on a separate domain/hosting so that people don't feel the need to churn through accounts with bots etc. and the load can be separated out. Hence this page: https://www.exchangerate-api.com/docs/free My signup form actually automatically redirects some classes of disposable email, bot signup etc. to this page!

2. Make sure that anything particularly resource intensive or that's a good reason to sign up for my service is only accessible after payment. I would love to give out more functionality for free but unfortunately the people that take advantage mean it's just not economically possible.

So for me the main reason to get an email address is 1.) so that users can have a better experience - get usage notifications, updates about the API that might affect them, share the account with a colleague etc.

And 2.) so that business users can be satisfied. Pretty much anyone running a company that is relying on an API will want to have an account, see how the upgrade process would work if they needed it etc. even if they're only starting off with a free plan.