If anyone needs a palate cleanser after listening to a depressing ATC recording, I can recommend this heartwarming first time solo flying teenager dealing with her landing gear coming off after takeoff.
https://www.youtube.com/watch?v=kZ5q7Iv5wTM
I remember reading --- and vehemently disagreeing --- with the report on the incidents, which danced around the matter but didn't point directly at the underlying cause: excessive complexity in the software, which easily created bugs and hid them. For example, they used multiple threads and a whole OS, when a simple loop would've been sufficient, perhaps in a misguided attempt at trying to keep the UI "responsive"; there would not be any race conditions if everything ran in the same thread.
As Tony Hoare says: "There are two ways to develop software: Make it so simple that there are obviously no bugs, or so complex that there are no obvious bugs."
I happened to come across her on 60 Minutes a couple of weeks ago, and that interview seemed awkward and sound-bitey to me. Thinking that she just might not be great at short-form segments I dug a little deeper and found an awesome long-form interview that she did with the Council on Foreign Relations. I highly recommend this to get a feel for what she is actually like as a policy person. She really impressed me.
For getting started, I'd recommend https://huggingface.co/autotrain - you should be able to find docs on the CLI which can let you do your first training run w/ a single command (which includes automatically pulling the model and training dataset from Huggingface). As long as you have an Nvidia GPU w/ enough VRAM should take only a few hours to tune a 3B model on a small dataset like Alpaca.
The article has some helpful points. But as a programmer-SAAS-founder-who-took-over-ads operation, I have some tips on some insights we gleaned doing paid ads (and getting it to be profitable for us):
1. Most important tip: is your product ready for ads?
- Do not do paid ads too early.
- Do it once you know that your product is compelling to your target audience.
- Ads are likely an expensive way of putting your product in front of an audience.
- No matter how good the ad operation, unless your product can convince a user to stay and explore it further, you've just gifted money to Google/X/Meta whoever.
- If you haven't already, sometimes when you think you want ads, what you more likely and more urgently need is better SEO optimization
2. The quality of your ad is important, but your on-boarding flows are way more important still.
- Most of the time, when we debugged why an ad wasn't showing conversions, rather than anything inherent to the ad, we found that it was the flows the user encountered _AFTER_ landing on the platform that made the performance suffer.
- In some cases, it's quite trivial: eg. one of our ads were performing poorly because the conversion criterion was a user login. And the login button ended up _slightly_ below the first 'fold' or view that a user saw. That tiny scroll we took for granted killed performance.
3. As a founder, learn the basics
- This is not rocket science, no matter how complex an agency/ad expert may make it look.
- There are some basic jargon that will be thrown around ('Target CPA', 'CPC', 'CTR', 'Impression share'); don't be intimidated
- Take the time to dig into the details
- They are not complicated and are worth your time especially as an early stage startup
- Don't assume that your 'Ad expert' or 'Ad agency' has 'got this'.
- At least early on, monitor the vital stats closely on weekly reviews
- Ad agencies especially struggle with understanding nuances of your business. So make sure to help them in early days.
4. Targeting Awareness/Consideration/Conversion
- Here I have to politely disagree with the article
- Focus on conversion keywords exclusively to begin with!
- These will give you low volume traffic, but the quality will likely be much higher
- Conversion keywords are also a great way to lock down the basics of your ad operation before blowing money on broad match 'awareness' keywords
- Most importantly, unless your competition is play dirty and advertising on your branded keywords, don't do it.
- Do NOT advertise on your own branded keywords, at least to begin with.
- Most of the audience that used your brand keywords to get to your site are essentially just repeat users using your ad as the quickest navigation link. Yikes!
5. Plug the leaks, set tight spend limits
- You'll find that while your running ads, you are in a somewhat adversarial dance with the ads platform
- Some caveats (also mentioned in the article)
- Ad reps (mostly) give poor advice, sometimes on borderline bad faith. We quickly learnt to disregard most of what they say. (But be polite, they're trying to make a living and they don't work for you.)
- (Also mentioned in the article) Do not accept any 'auto optimization' options from the ads platform. They mostly don't work.
- Set tight limits on spends for EVERYTHING in the beginning. I cannot emphasize this enough. Start small and slowly and incrementally crank up numbers, whether it be spend limits per ad group, target CPA values, CPC values - whatever. Patience is a big virtue here
- If you're running display ads, there are many more leaks to be plugged: disallow apps if you can (article mentions why), and disallow scammy sites that place ads strategically to get stray clicks.
- For display ads, controlling 'placement' also helps a lot
6. Read up `r/PPC` on Reddit
- Especially the old, well rated posts here.
- They're a gold mine of war stories from other people who got burnt doing PPC, whose mistakes you can avoid.
An obvious question you face when deploying something like FDB is how to write your app on top of it. With FDB it's like RocksDB. You get a transactional key/value store, but that's a very low level interface for apps to work with.
FDB provides "layers", such as the Record layer. It helps map data to keys and values. But a more sophisticated solution that I sometimes wish would take off is this library:
It's a small(ish) open source project that implements an ORM-like API but significantly cleaned up, and it can run on any K/V backend. There's an FDB plugin for it, so you can connect your app directly to an FDB cluster using it. And with that you get built-in indexing, derived data, triggers, you can do queries using the Java collections API, there's a CLI, there's an API for making GUIs and everything else you might need for a business CRUD app. It's got a paper of its own and is quite impressive.
There are a few big gaps vs an RDBMS though:
1. There's no query planner. You write your own plans by using functional maps/filters/folds etc in regular Java (or Kotlin or Python or any other language that can run on the JVM).
2. It's weak on analytics, because there's no access control and the ad-hoc query language is less convenient than SQL.
3. There's no network protocol other than FDB itself, which assumes low latency networks. So if there's a big distance between the user generating the queries and the servers, you have a problem and will need to introduce an app specific protocol (or move the code).
I think the better version of these ideas is in Jason Cohen's classic "Designing the Ideal Bootstrapped Business" talk.[0, 1]
The difference is that Jason Cohen's advice is based on personal experience growing four businesses to over $1M/yr in revenue. I'm not seeing what qualifies this author to give such broad, sweeping advice about bootstrapping.
> "Use single or multiple fields depending on your user’s needs. Not everyone’s name fits the first-name, last-name format. Using multiple name fields mean there’s more risk that a person’s name will not fit the format you’ve chosen and that it is entered incorrectly."
and
> "Avoid asking users for their title. It’s extra work for them and you’re asking them to potentially reveal their gender and marital status, which they may not want to do."
and
> "If your service stores personal information, you should allow users to update their details, including their name. Allowing users to change their name helps your service respect their personal identity. It also means they can continue using your service without having to start over. People change their name for many reasons. For example, because of a change in marital status, family situation or gender. Avoid making it hard for users to change their name. As well as causing them distress, it may make them reluctant to use your service."
Just want to add, I followed pretty much the same path with Windmill [1], which is also in the developer tool space, and also open-source. Built everything solo for 5 months. I thought it would be impossible to get into YC, it is not and I was fortunate enough to join YC on the latest batch, on my first try [2].
Getting into YC changed the course of the company, increased many orders of magnitude my ambition and made fundraising much easier. Most importantly, even though I worked in tech in the bay many moons ago, at the time I was very isolated in Paris and thought I understood the startup game but I did not really. Being part of a cohort like YC with like-minded amazing peers, truly felt like I was able to go up to speed on many subjects that would have been out of reach for a solo founder.
If you are a solo technical founder and considering applying to YC, reach out to me, I am more than happy to help.
There's a hidden setting when configuring geo on campaigns.
By default it's set to "People -interested- in your target location" . You need to change it to "People who are -in- your target location".
This setting is hidden under a toggle, so it's very easy to miss. Definitely a dark pattern and results in a lot of garbage clicks if you overlook that setting.
This is just one of many dark patterns which makes Google Ads effective only for people willing to spend the time tuning and tweaking every single setting.
A big part of the problem is Google themselves - they say always use "broad" keyword matches (and of course it's the default). Broad matches are really not good for most campaigns unless you have an extremely large budget, yet if you read their documentation they heavily encourage it.
While we're at it...
1) Never enable the "auto apply recommendations" setting. If you do, it gives Google free reign to modify your campaigns (this has always resulted in worse performance and more spend in my experience)
2) Never listen to a google ads rep if they call. Once you're spending enough, they'll call you every week trying to convince you to change various settings. 95% of the time their advice is just plain bad. The quality of the advice does increase once you're spending enough and get assigned more senior reps. But even the senior reps are there to get you to spend more money, their job is not to make your campaigns more effective, "ad specialists" are simply sales people in disguise.
We love Tailscale. Everyone employee has it, and we use it to provide access to dev, staging, and prod environments as well.
Fun little thing we did with it: nobody can access the prod network without requesting access via a Slack bot (powered by https://indent.com/). So somebody requests access, another authorized person approves it, and the Tailscale ACLs are updated for X minutes and then reset.
Access to secure environments is super low friction but more secure (with fantastic audit trails) than ever.
Yes, it is a little bit of a pain in the neck however. Basically you are going to implement your own ZBA with a positive pay ( while some form of a PP may be available to non-business accounts I have never heard of a ZBA + PP combination ). You will probably need to chat with the branch manager in a midsized/regional/community bank as everyone else would look at you as if you had two heads.
The good security policy is this:
1. Have an incoming account. That's the account number that you would be giving to payroll companies/account into which you would get deposits. You should presume that information about this account is known and all the money in this account is at risk. Which means that as soon as money becomes marked as "available" in this account, you have to move the money away.
2. Have a main funds account that has a positive pay type service turned on if your bank offers it. Positive Pay service is the "Notify customer about pending transactions and wait for customer to acknowledge them. If a customer does not acknowledge them by the cut off window, decline a transaction." This is typically done on a treasury management or cash management website of the bank though as recently as two years ago a certain reasonably well known bank still used a fax as a method of sending positive pay requests to customers and getting it back from customers.
If your bank does not offer a positive pay type service, have this account coded for no withdrawals. This means that all debit transactions against this account will be declined unless someone on a platform side of the bank overrides it ( most banks have teller sides and platform sides -- platform side are people that you go to talk to inside the branch to deal with the issues with your account ).
3. Have a payment account that you would use to pay others. If your bank has a positive pay service, add it to this account as well. This is the account that you will fund from (2) when you know the amounts of outgoing payments. Money in this account is also at risk which is why you should only fund it with the minimum needed to cover the outstanding payments. If you have "enough money not to care if you are out of a few thousand for a couple of months" you can keep $3k-5k here at all times and just replenish it from (2) once or twice a month -- while this would leave you exposed for $3k-5k it will still protect a bulk of your cash and make your life easier. All of this is a matter of convenience vs. risk -- you should know what's your average monthly spend is and you want to expose not more than that plus a few percent for variance.
4. Have a nightly/daily/hourly sweep of all available funds from account (1) to account (2). It can either be done using a service the bank provides, or using online account transfer. Definitely sweep away immediately after a large payment ( such as a paycheck ) or electronic/non-electronic checks post to this account.
5. No debit transactions can post to the account (2) [including bank internal transactions] without an override ( for a coded account) or without a positive pay acknowledgement for a positive pay account. That of course means that if this is not a positive pay account, you would need to show up physically at the bank and have one of the tellers after the teller checks your ID process a transfer of funds from (2) to (3).
If you have a significant amount of money, you should have this setup in several banks.
Remember, your goal is to make issues with money less stressful while you are resolving them. At the end of the day, you will be made whole because we have a fairly strong legal system to get redress. You are trying to make sure that you still have the money while you are using the legal system to deal with the issues.
Source: Did consulting for execs at medium sized banks.
