Flicflac

I recently did an interview with Acquire.com on my experience buying and selling a company on their website.

One tip I share in the interview is how to properly value a company.

Most of the time, we value companies based on a multiple of revenue. Eg If a company makes 10k/year and we give it a 3x multiple, then the company is worth 30k.

However, for smaller companies this is actually a mistake because it doesn’t account for the value of the IP itself. Especially at low revenues, the code and IP are worth far more than the revenue it generates.

So the proper way to value a company, especially if it doesn’t make that much money, is to ask these two questions:

1) How much would you pay for this company if it made 0 revenue? 2) Then add on the revenue multiple on top of your answer to 1).

And that’s the real value of the company.

In full transparency, I didn't make much on the acquisition, maybe $15k from the acquisition + revenue which I had to split with a partner and to cover some costs. But it was still an experience.

If you have any more questions on buying and selling companies, I’ll answer them below.

My full interview is here: https://acquire.com/blog/how-to-buy-and-sell-a-saas-business...

We often think building courses is the ultimate passive income play. But the reality is that selling a course is neither easy nor passive.

1. I only made about $1500 from two courses I built in the last 6 months.

Considering I spent 3 months on the first course, and 2 weeks on the second, I probably won’t break-even on either course for a long time.

2. I also have a sales conversion rate of 1.5%. That means for every 100 people who land on my course pages, I can expect to make 1.5 sales.

Driving 100 people to a course page is actually very difficult, as it requires somewhere between 50k-100k post impressions to get there.

While attainable for people with a mid-5 figure audience, I’d have to post an insane amount to get that many post impressions to make a sale.

Stories of people making lots of money from course sales are anomalies. The reality is that most course creators likely won’t break-even on their course.

> Why study years and years of how computers work, to then think about people and business problems?

Because in school, you study engineering in a vacuum. In the real-world, you have financial constraints, time constraints, and business goals to meet.

thank you for the kind words. i'm indeed getting close to 30.

agreed - junior engineers don't recognize that they even need to look at other tools. hence why they end up using the wrong tools

good point, thanks for sharing

Hi everyone, OP here :) In this article, I discuss 3 common mistakes that junior engineers make that 10x engineers don't. 3 key takeaways:

1) 10x engineers are investors first and foremost. Their work is an investment of their time, and they go for tasks that have the highest ROI. 2) 10x engineers are not "lone geniuses". They know when and who to ask for help. 2) Being difficult to work with instantly nullifies the 10x factor. Engineering is hard enough - don't let your ego wash out your 10x engineering skills.

DM's always open at twitter.com/_michaellin :)

hey HN, original writer here, just saying hi!

Two main takeaways from this article:

1) Before starting a DAO, always compare it to its web2 version. Example: before you start a crowdfund DAO, why wouldn't a web2 GoFundMe work just as well?

2) A DAO is only as strong as decentralized as its most centralized link. If treasury management or voting isn't decentralized, the organization can be co-opted by bad actors. If a DAO is ruled by a multi-sig wallet, what's stopping the voters from colluding with each other to steal the funds?

If you liked this article or wanna talk crypto more, DM's always open at twitter.com/_michaellin . Cheers!

Hi OP here!

A few months ago I bought a basic screen recording website off microacquire. As I tried to grow the website, I noticed that more and more people were using it for customer support use cases eg recording bugs, demo-ing steps etc.

Since then I've pivoted it into a full-fledged customer support tool. We've had a lot of users interested in the enterprise aspects - embedding a screen recording on their website, white-labelling, CNAME support, and gathering feedback via a simple widget.

I'd love to hear what y'all think!

We are working on adding features like 1) so stay tuned!

love the detailed feedback. thank you

Hi OP here! I created recordjoy.com to make it easy to record your screen and share it quickly. No installation needed.

I personally have an edtech background, and made this to show my students how to solve math problems.

However, as it has grown I've seen people use it to record bugs and demo how to use their website. Hope hackers and educators find this useful. I'd love to hear your comments!

Hey evangelosdotnl,

Tech talks usually make me fall asleep, but that was an amazing talk. Thanks for sharing.

I'd love to chat more sometime. Please reach out to me at schedulerapi (at) gmail.com if interested.

Hey evengelosdotnl, great comment. A lot to unpack here. To address both points:

>>>Why would you need to have a delay of delivery at the first place?

1) Emails - Let's say you want to send a reminder email a month in advance. You usually put emails on a queue to go out, but since this is scheduled so far in advance, you need a way to store the request and publish it back to the queue to send a month later. Then you could use schedulerAPI + your emailService to achieve this reminder email effect.

You could extend this to any service that needs a delay. Eg if you need to schedule billing, you can call schedulerAPI + stripe API, delay texts you use scheduler API + twilio API, where each queue message is a request to bill or message someone).

2) Handling retries - Sometimes if a message fails you want to retry with exponential backoffs. This requires re-enqueuing the message with longer delays. You could just call schedulerAPI w/ longer delays to achieve this.

>>> CQRS Implementation for handling queues

Thanks for sharing this, I have never heard about this before. CQRS seems consistent with both scheduler API and microservices architecture in general. From my quick read of this, it's basically saying to spread out a monolith service that handles all CRUD operations in one service into separate services if the model for each operation is different. So instead of one service that handles all writes and reads to a table, you have two: one that handles reads, one that handles writes because the models for both are different.

Queue message scheduling fits well with CQRS. The queues and scheduling are different problems. The queues handle high throughput messaging, whereas scheduling is more of a storage problem (if you delay a request you need to store it somehow and pop-it out when you need it). So it makes sense based on CQRS architecture to separate the two out because they are fundamentally different models. That could explain why scheduling queue messages has never been a first class citizen in any MQ so far.