388 karma · joined January 28, 2021
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!
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...
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.
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.
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.
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!
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.
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.
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.
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...
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...
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.
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...
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!
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.
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.
Basically hand out tons of short lived credentials right from a widget on the main landing page, together with each API response giving a link to a signup form that can convert the key into a fully fledged account.
Thanks for the suggestion!
You can see it here: https://www.exchangerate-api.com/docs/free
That said, as much as some users want an open endpoint with zero authentication there are many others who want an actual account, commercial support, high availability, more features etc. These users are also the ones that pay for development, infrastructure etc. so my service has to be 95% built around the flow that includes signup.
I've had a fair number of users send me feedback saying this isn't the best practice, I should use tokens in HTTP auth headers or use various other auth schemes.
But from my perspective, for an API that is offering really very simple functionality, using HTTPS & not handling user data etc. then this is quite OK - especially when you consider the benefits of how simple it is to get up and running.
I have quite a few university course conveners include my free API in their entry level CS classes because it's super fast & rewarding for students to go from finding my API to then having a JSON object in their code, no tokens required!
I really can't think of any other suggestions - your landing page is excellent, fast and I imagine highly converting with all the social proof. I also like the specific landing pages for each customer segment a lot, I really need to do that for my service.
Your site inspires me to work more on mine!
I've specifically eliminated some of the steps this article cites in its example of a tedious flow - for instance I changed user accounts to be confirmed by default and then only disable them retroactively if a user doesn't click the activation link within 24 hours. This way you don't need to wait for the confirmation email. Even though I use Postmark delivery times can be surprisingly variable.
I'm not sure how I could further improve the current flow, which is 1. put your email into the landing page, 2. then choose a password for your account, then 3. you're presented with an example request format including your already activated API key. Suggestions welcome!
I guess because the scope of my service is so limited it's easy to have this fast flow, no complex libraries or auth is involved.
One thing that amazes me though is some of the places people rely on free services. As someone who has run a free and open access API for over 10 years now it never ceases to amaze me how people integrate free services into critical production code and high volume, high availability contexts.
Sometimes I can see from my logs and sometimes because users end up contacting me - developers happily include the version of my API that doesn't require any API key [2] in large corporate ERPs, apps in the Atlassian app store, shopping carts of super high volume e-commerce stores etc. etc.
Obviously I take great care in how my free APIs are provisioned and monitored, but it is still shocking to me that people just pick an API off a list and then rely on it in a system that probably cost millions in developer salaries to build...
[1] https://www.exchangerate-api.com [2] https://www.exchangerate-api.com/docs/free
On the one hand you have returns available to anyone prepared to invest consistently in the stock market across the last 30 years that are both well documented and very substantial. People like Warren Buffet & boggleheads make data-backed arguments about how well you could have done if you put money in even just broad index-tracking funds.
And yet on the other hand there are two massively powerful groups with materially more leverage and informational "edge" within the system compared to all the people with a 401K. These are the executives who actually run the public corporations (and can choose their own compensation as a class via board/exec rotation & internal influence) and the financial firms that are embedded both in the firms' operation and also essentially setting/playing the rules of the meta-game as evidenced by articles like this.
It feels like the fact that there are any returns left for a retail investor in public stock market investing speaks more to the quantities of wealth creation taking place than the absence of this sort of outrageous market rule capture.
Two disclaimers: 1.) the slider for wealth "creation" on the public markets in the US seems fairly obviously to be being dragged from innovation to ZIRP... whole separate matter. 2.) at a whole-society level obviously the availability of public market returns is limited to a tiny sliver of the population with the means to invest, so when I say "bounty of capitalism" above I'm more referring just to the sum of financial profits as a result of the system.
"If you're collecting personal data, 'how should I protect this?' is actually your third question.
'Should I collect this?' is only the second question.
The first question is 'what would the worst people do if they got hold of this?'"