However, losing google cloud domains is hard to defend, and makes promoting GCP hard.
272 karma · joined August 3, 2022
However, losing google cloud domains is hard to defend, and makes promoting GCP hard.
Is there any way to get that time from 10-12 hours down to say 0-1 hour... while still maintaining the bulk of the savings?
If so, that might be a good value add.
For example, learning to pitch a startup is valuable IMO. At the start it doesn't seem to make much sense - why these details, but not others... but by the end you start to understand the questions investors want answered:
1) What is the problem?
2) What is your solution?
3) How do you make money?
4) How much money could you make?
5) Are you the right people to actually build this?
6) What is this going to cost to invest in?
https://www.ycombinator.com/library/2u-how-to-build-your-see...
The rest of it is from running a business, and understanding that businesses need a way to attract customers (typically paid) and idealy make, or have a plan to make, more money than it costs to aquire and service a customer.
Consider getting a virtual office (e.g. regus) for mail. You don't wnat random people rocking up at your door, and you don't want to have to change every address if you ever move.
So my first question are always:
1) What does it cost to aquire a customer (CAC)?
2) How much does a customer pay (REVENUE)?
3) How many customers are there (TAM)?
4) How much does it cost to service a customer (GROSS MARGIN)?
Let's answer these:
1) No information provided, but it's probably not cheap given there is plenty of competition. You can try to rely on word of mouth/focus on the FSBO niche... but this is a critical question to answer. (High CAC?)
2) This is easy, you charge $995/listing. Is this less or more than 1? No idea. (Low REVENUE!)
3) We can estimate this - you mention 500k FSBO happen each year. Let's say you're really successful, and capture 50k sales a year. (Low TAM!)
That's a $50M/year revenue stream. As an induvidual that sounds large... but as a business that sounds pretty small - for context redfin spent $158M in marketing alone in 2022.
4) Cost to service customer... I imagine overtime and scale this could be reduced, but to what level? (Possibly okay GROSS MARGIN).
As presented, and filling in the blanks, I think this is a currently a weak business model - high CAC, low Revenue and small TAM... this is going to make everything you do harder than it should be.
----
Notes on the website:
The website doesn't really sell the value of using your service.
The headline says 'Zero commissions'. This doesn't actually add any value to the seller.
Your bullet points for 'sellers' are questionable:
Set your home apart? Really? Who will see these listings? How will they know it's easy?
Deal directly with buyers? This sounds like work. Why do I as a seller want more work?
Close and Save? How does this help me close? What am I saving?
----
A different approach. Keep in mind I don't know your target customers, but here are some idea's:
1) Charge 10x as much - $9,995. Maybe on a success only model.
This instantly 10x's your possible revenue and TAM... and focusses your time on early adopters who see value in your service, not cheapskates who are not going to do the work and leave bad feedback. Use the extra funds to market and hire!
Alt: Keep cheap, but go deep into viral + addons. More complex, so not my preferred route.
2) Work on understanding the customer and figuring out thier pain points. Adjust marketing to fit:
E.g. Save $X0,000 and be in control with PropBox!
E.g. All the control of FSBO, but none of the paperwork!
E.g. Sell your home faster, on your own terms, with PropBox.
3) Serve customers via concierge model until marketing/CAC is dialled in. Then focus on automation.
M2 Ultra has 800GB/s, which sounds like a lot until you remember a Xbox Series X has 560GB/s and costs $499. Or spend $800 and get a 7900 XT which has 800GB/s.
Think of the Ultra more of a GPU that happens to have CPU built in.
Keep in mind certain crowd-funding is legal in US.
Dropping cpu and GPU frequencies even a few % might have a significant impact.
If you think reality is important, then it's upon you to define reality and why you think it's important.
1) What makes reality important? 2) What is the definition of reality?
> In all VR spaces you will absolutely be the product while also being milked for every single micro-transaction you can pay.
How does that differ from reality? Are you not paying for the walls that are presumably around you right now?
I can compile code on my laptop - can I do that on a vision?
I can plug a xbox on my TV, or watch it with 4 people. Can I do that with a vision?
Did he? I see no evidence Twitter was at risk of total bankruptcy before he bought it.
> Still SpaceX and Tesla are examples of effectiveness overall
Which reinforces my point - both were formed and successful while Elon had good optics.
I'd argue part of what made Musk's companies so successful was the optics - he was seen as a visionary, building the future - ergo customers and engineers alike wanted to associate with him.
Since the decline in his optics over the last few years, has he been an effective leader? Twitter does not seem to support that notion.
Lying depends upon context.
It's not even a high premium if you need what cloud offerings have.
Management is expensive. Scaling is expensive. Security and compliance is expensive.
Cloud isn't for everyone, but when you need what it offers it can be amazingly cost effective.
This is a nonsensical claim. Nothing about serverless requires 'spaghetti' code. Vice versa, nothing aboud non-serverless deployments suddenly ensures well written code.
> Cold boot performance is highly varible and generally worsens with added function complexity but this depends on tech choice.
For many use-cases this isn't a problem. If it is a problem, then sure, don't use serverless.
> Infinite concurrency is a bit of a curse. Want to use that MySQL DB that contains all your business critical data? Better use some MySQL Serverless proxy nonsense because unbounded connections isn't fun.
Sure, but:
A) You get a lot of scalability before that becomes an issue. B) Setting up a proxy isn't exactly hard. (I get one for free since we use Hasura).
> Lock-in is awful, migration story is awful.
This is nonsense.
Our serverless code runs in docker containers, running perfectly normal ASP.net code. This code could be deployed to a VM, appengine, or k8s in less than a day if needed.
> Amount of Infrastructure as Code overhead, ala Terraform, CloudFormation, whatever else floats your boat to support serverless is insane. The sheer number of objects that need to defined, kept in sync etc is just bonkers. Not to mention if you have multiple services setup like this it's all boilerplate you either need to abstract or carry around.
One of the advantages of our use of serverless is that we don't yet need any of that complexity.
> Hides serious programming deficiencies like memory leaks because context is thrown away after servicing request.
What you descried is literally not a serious deficiencies. If you code leaks memory, but never runs long enough for that to have meaningful impact, it's not a problem.
> Unpredictable runtime makes observability more complicated, probably forcing you into poor decisions as a result, i.e prom push gateway.
The serverless solutions we use have observability built in for free... and datadog automatically can pull that in if you wnat a starting point for more.
> Runtime/execution time limits mean people trying to do all-serverless end up doing horrible things to accomplish long-running tasks.
If you have something that must be long running, serveless isn't a great pick for that one thing (at least, witht he solutions I'm aware of).
That said, there are some elegant ways to handle that using serverless (e.g. by breaking it into smaller tasks with shorter durations)... and going non-serverless isn't a silver bullet, I've seen terrible architectures for long-running code in all kinds of deployments.
> All of the above leads to increasing pressure to make poor architectural decisions to work around limitations of the runtime.
Completely ignoring that serverless can encourage better architectural decisions.
> EDIT: Actually I forgot the worst con. The cost. The $/CPU/RAM cost of Serverless is beyond bonkers. When I was pricing up Cloud Functions vs Spot instances on GKE I think I came to the conclusion Cloud Functions are about 300x as expensive.
Curious.
Let's have a 1s task on Cloud Run with 1 CPU and 1GB of memory:
CPU: $0.00002400/s Memory: $0.00000250/s Request: $0.40 / million
Total = $0.0000269 for 1 request lasting 1s.
Current spot pricing for C3 instances is:
$0.003086 / vCPU hour $0.000413 / GB hour
Or for 1s that would be: 0.00000097/s
Which is 27x cheaper - so you're already off by an order of a magnitude.
It gets worse - that's 1GB of RAM, however the VM needs RAM for it's own OS etc, so maybe you need to provision 2GB of memory, a bit more CPU etc.
The minimum billing time for compute instances according to docs is 60s... so 60x cost if you only need to do this hourly or less.
You're entirely responsible for all time spent, including startup, shut down, idle etc. This just adds more and more cost.
The expected availability model is completely different - serverless should be available in milliseconds, seconds at the worst. Spot instances have no such expectations.
It's a fundamentally different model - a spot VM can't loadbalance, serve code or anything without devops. So now we're spending likely $XXX/hour on devops to try to save fractions of pennies an hour.
When this is all said and done, I don't think you really understand the cost or use-cases of serverless well - and dramatically underestimate the costs of the solutions you present.
We do this in a handful of small services, none of which gets much traffic. The alternatives (e.g. app-engine, container in vm, or k8s) all require more infrastructure, would cost more (no scaling to zero), and are overall less suited for the kinds of problems we expect to see.
Ergo you only see cases where it isn't working well.
However the article does little to explore this concept, and makes unconvincing and contradictory arguments re sustainability.
This goes to the team. If you want to build a startup selling to enterprise, it helps to have a co-founder that has the skills/experiance to do this.
Err... what?
How do you think businesses work?
2) In practice having the ability to run reports on your data can be super important and useful.
I'm still confused at the point you're trying to make.
This argument confuses an image and the style. The former is copyrightable, the latter is not.