[HN Gopher] Gitlab's Startup Acquisition Process
___________________________________________________________________
Gitlab's Startup Acquisition Process
Author : walterbell
Score : 208 points
Date : 2023-02-20 10:32 UTC (12 hours ago)
(HTM) web link (about.gitlab.com)
(TXT) w3m dump (about.gitlab.com)
| LoverKiddo12 wrote:
| [dead]
| paultopia wrote:
| Forgot step 6, layoffs.
| diceduckmonk wrote:
| > The call must include the Product champion and may also include
| Stage Leaders
|
| I was not familiar with these roles before this article. Are they
| more colloquially known in the M&A world ?
| rubidium wrote:
| They're roles (intentionally flexible in the who) ascribed for
| the particular acquisition target. In M&A you have 2 main
| stages, the (1) find interesting targets and confirm they're
| interesting, and (2) the purchase and integration.
|
| The champion will often lead (1) but if they're too busy may
| have a defined stage leader to make sure the trains keep moving
| well. In the later stage of (2) the stage leader will typically
| be someone with experience integrating companies. It's an art.
|
| I wouldn't say they're agreed on definitions, but I got what
| they meant from my exposure to M&A.
| jsty wrote:
| From the context Product Champion would seem to be using
| "champion" as in the B2B sales world - usually someone
| advocating the purchase of a particular vendor's solutions,
| here someone inside GitLab advocating to buy a particular
| company.
| dnsmichi wrote:
| GitLab team member here.
|
| "Stage leaders" is specific to GitLab, referring to the stages
| of the DevOps lifecycle [1]. Stages are part of the product
| hierarchy definition [2], with sections, stages, groups,
| categories, features. Maybe the term is similar to "product
| group leader" in other areas.
|
| FYI, created a merge request to link the product handbook from
| the acquisitions handbook, providing more context on stage
| leaders. [3]
|
| [1]
| https://about.gitlab.com/handbook/product/categories/#devops...
|
| [2]
| https://about.gitlab.com/handbook/product/categories/#hierar...
|
| [3] https://gitlab.com/gitlab-com/www-gitlab-
| com/-/merge_request...
| jasonjei wrote:
| This is a great process write up, but I was surprised how little
| was addressed about existing target company customer support and
| communication. There is ample support for internal stakeholders,
| but what about customers of the target company?
|
| I have found that as a customer of products acquired by larger
| companies, the customers of products being acquired and
| integrated into a larger product are often forgotten and
| sidelined.
| breck wrote:
| This is awesome. Kudos to Gitlab for open sourcing this.
| FearlessNebula wrote:
| Why does everything need to be acquired these days? Why do we
| consolidate everything into a few big companies? Why can't we
| just have technology spread out across multiple players.
| jen20 wrote:
| Because VCs need returns, and many of these companies wouldn't
| even exist without VC money.
| jacquesm wrote:
| Or because founders want to diversify. A founder is a non-
| diversified investor...
| hummus_bae wrote:
| [dead]
| tapotatonumber9 wrote:
| Can anyone expand "MVC" as used in this guide? It appears as
|
| "Outline a simple integration timeline for those features,
| considering an MVC release on the first month ..."
|
| I'm only familiar with this meaning Model-View-Controller. In
| this context I'd probably expect "POC".
| sjhewitt wrote:
| "Minimal Viable Change"
|
| https://about.gitlab.com/handbook/product/product-principles...
| tapotatonumber9 wrote:
| Thank you! This might be a useful term of art to bandy about
| my current work situation.
| pdq wrote:
| This is an impressively thorough and quite insightful M&A
| overview.
|
| However, it is completely one-sided toward the buyer (ie GitLab).
|
| As a seller, I'd be wary of going through even a fraction of the
| pre-term-sheet diligence and disclosure, without getting to a
| ballpark on acquisition price (or price methodology) beforehand.
|
| Also, they don't mention, but having escrow set up as an
| insurance in case the acquirer backs out also seems necessary (ie
| % of the deal held with third party). Otherwise you are basically
| giving away all your company secrets and time, and if they back
| out, you get nothing.
|
| I'd guess YCombinator has something equivalent from the seller
| side. It would be great if they shared their M&A handbook at some
| point in the future, although I understand it's probably
| considered "secret sauce".
| datasert wrote:
| Gitlab's Handbook [0] (which this article is part of) is an
| invaluable resource for any first time founders. This is one of
| the best contribution of Gitlab to the community in my opinion.
|
| [0] https://about.gitlab.com/handbook
| [deleted]
| ankit70 wrote:
| Feels like created on Workflowy/RoamResearch with nested bullets.
| Great!
| mkeeter wrote:
| One interesting tidbit from the handbook:
|
| A good acquisition target company should be "willing to sunset
| old customers within 90 days or less, with an option to
| transition to GitLab" [1]
|
| Given the pattern of startups being acquired, announcing "nothing
| will change", then sunsetting their original product [2], it's
| interesting to see this spelled out so plainly.
|
| [1]
| https://about.gitlab.com/handbook/acquisitions/#acquisition-...
|
| [2] https://ourincrediblejourney.tumblr.com/ is the canonical
| repository of these emails
| mbesto wrote:
| Since this documentation heavily refers to Technical Due
| Diligence processes, I thought I'd offer an "AmA" since this is
| what I do for a living (personally have conducted 400+ Tech DD
| projects).
|
| Disclaimer - I'm not a GitLab employee and they are not a client
| of mine, but their documented processes are very synonymous with
| what I do.
| DishyDev wrote:
| I love the idea of doing independent technical due diligence
| work after enjoying doing software auditing and investigations
| in my current job. Looking at Gitlab's processes it seems like
| company structure, finances and legal checks make up a lot of
| the investigation. The software/infra/tech side seems quite
| short (Gitlab suggest their early technical diligence should be
| turned around in 2-3 days).
|
| Do you think there's enough demand out there to have a company
| that does just technical (e.g. software quality, security) due
| diligence?
| mbesto wrote:
| > Do you think there's enough demand out there to have a
| company that does just technical (e.g. software quality,
| security) due diligence?
|
| My company (used to, we've grown to do other things) only do
| Tech DD and we've done really well, so the answer is yes.
| According to Pitchbook there are about ~3,000 software
| company acquisitions every year - so that might tell you how
| much potential business there is.
| [deleted]
| ericb wrote:
| Thanks!
|
| * What are the most common gotchas?
|
| * What tools do you use to do the technical due diligence?
|
| * What would you suggest to prepare for it?
|
| * What would acing it look like?
| mbesto wrote:
| * What are the most common gotchas?
|
| Surprises! We don't like surprises, and nor do our clients.
| From a tech perspective - dated tech, unmanageable (or no
| clarity of) tech debt, NIH syndrom
|
| * What tools do you use to do the technical due diligence?
|
| OSS scanning and security scans mostly
|
| * What would you suggest to prepare for it?
|
| I'l try to answer this simply, which is - read GitLabs
| documentation and if you have similar and more importantly -
| actually operate this way, then you'll be more than prepared.
|
| * What would acing it look like?
|
| As I mentioned below, there is no pass/fail. Acing it is - be
| honest, be prepared, and have a plan (not for the tech dd
| itself, but rather a plan for your business).
| ollien wrote:
| What makes something like outdated tech a "surprise",
| rather than just "reality"? As in it was actively hidden
| from you, or just not something anyone thought worth
| mentioning until it came time to plow through the code?
| mbesto wrote:
| "Surprise" could be interpreted a few different ways.
| Here's an example to elaborate:
|
| - Company being acquired ("Target") built a web based
| application in the mid-2000's using VB.NET and each
| client installed the software. It requires a desktop
| widget to be installed at their clients locations to talk
| back to the VB.NET web backend. In 2016 they switched
| their licensing model from perpetual license to
| subscription and now the web application is hosted by the
| target and not the clients.
|
| - Target tells acquirer they have a "SaaS" application.
|
| So, now its a VB. NET web app with single tenants hosted
| on the Target's data centers. Not untenable, but the
| acquirer was probably expecting a multi-tenant SaaS web
| app in a more generally supported web framework.
|
| And, yes I've absolutely seen this case (or something
| very similar) in the wild.
| biztos wrote:
| Do you look at codebase quality?
|
| As in, have someone good at Language X go through the
| target's repos and deliver a verdict on how good the actual
| code is, and how well it's organized etc?
| mbesto wrote:
| More or less yes. The tooling for this is getting much
| better.
| Closi wrote:
| I'm not OP, but when I experienced due dilligence the thing I
| found counter-intuitive was that 'looking really good at
| everything' isn't actually the best approach.
|
| As an example - it might be better that the company doing Due
| Dilligence finds you awful at sales during the DD phase,
| because they will see that you got revenue _despite_ poor
| sales technique and they will see it as an easy target for
| improvement / 'to generate value'. Companies want to
| identify ways that _they_ would be able to help the company
| they are aquiring.
|
| Not sure if this applies to Technical DD, but thought it was
| interesting enough to share!
| jacquesm wrote:
| Yes, that's called 'hidden upside'. You can of course also
| disclose this before DD. As a rule, surprises during the DD
| process are to be avoided if you can, even positive ones
| (because you may lose out on a bid from a party that would
| have bid if they had been aware of it).
|
| source: yaddp.
| mbesto wrote:
| Exactly this. You don't pass or fail Tech DD...it's more
| to provide comfort to the buyer.
| wslh wrote:
| OP is specifically talking about tech due diligence which
| is specific within due diligence in general.
|
| One thing that appear in tech due diligence is quality of
| the technical architecture and implementation, and security
| risks associated.
| jacquesm wrote:
| And: quality of the people... if there is one
| distinguishing factor it is that one. Bad tech can be
| fixed, and if there is a competent team that got put in
| charge of a pile of tech debt then there is hope.
| di456 wrote:
| > Customer list with name, monthly revenue, contract
| termination date and any other fields if relevant.
|
| Could you compare and contrast this analysis for companies with
| a small number of large customers, vs a large number of small
| customers? What are you looking for? What are examples of good
| or bad surprises?
| mbesto wrote:
| These are more business/commercial questions, but they
| typically manifest themselves in Tech DD when it comes to
| implementation, which is what we might look at.
| CSDude wrote:
| What's the rate of your reject rate, and what are the most
| common deal breakers, bad signs? It'd be helpful.
| mbesto wrote:
| So we just advise on things that might constitute as "red
| flags", however ultimately our clients make the decision to
| break a deal. I would say its about 5%~10% rejection rate
| (some clients are more risky than others), and it's very rare
| that tech alone is the deal breaker. When tech is an issue,
| it's usually combined with some business issue (example - it
| takes 3 months to onboard a new client and the company has
| little automation for data migration, so they won't scale
| well)
| brugidou wrote:
| How do you measure success? Do you follow up on these companies
| later on (acquired or not).
| paulgb wrote:
| I'm curious about your career path. Did you start by doing it
| in-house and then go into consulting? Are you at a big
| consultancy or do you run your own specialty DD consultancy?
| mbesto wrote:
| I love this question since my career path is so irregular.
| It'll take some time so lemme write a more detailed response
| in a bit.
| thiago_fm wrote:
| Also interested on your answer. I'd love to work on this
| full-time!
| yamtaddle wrote:
| Thirding. I've done a little of this as part of a job a
| while back and I think I'd really like doing more of it.
| Curious what kind of demand-volume there is for it, and
| especially if there are any adjacent services that people
| are willing to pay for (e.g. more social, looking into
| the management & process side of a tech org). Avenues for
| breaking in with sales for this, that kind of thing,
| would be greatly appreciated.
| mbesto wrote:
| I'll answer this in two parts:
|
| Me:
|
| I personally have a very atypical career so please take this
| with a grain of salt. That being said, I think my weird
| background helped me to excel in this space
|
| Here is my professional background - SAP
| Consultant working for SAP (Data Analytics & Reporting)
| - (Entrepreneur) Web Design Agency (failed) - SAP
| Consulting (3rd Party Partner) - (Entrepreneur)
| Startup (failed) - Management Consulting (we were
| doing about ~15 IT Due Diligence projects a year when I
| joined) - Left previous firm and started my own firm
| (Renna Partners), which exclusively focused on IT/Tech DDs
| (previous firm did IT strategy + DD was a small part of the
| overall biz) - Sold my firm to my competitor
| (Crosslake), which is who I work for now
|
| Experience that led to this type of work:
|
| I started as a consultant in SAP's support group. Oddly, at a
| young age this gave me exposure to the technical/operational
| challenges of M&A as I sat in on a high profile customer who
| bought SAP and BOBJ integrated products before the company
| merged, and then had to deal with the companies/tech talk to
| each other post close. This was more "in the trenches" than
| it was strategic, but it help formulate how I thought about
| the strategy of M&A for companies. I then taught myself to
| code when I tried doing a web design agency and a startup.
| Failed miserably, but gave me a ton of empathy about what its
| like to be a (1) a founder (2) an engineer and (3) a business
| operator. After my last startup failed, I called an old
| friend of mine and luckily they were hiring. Their IT DD
| practice was small (it was 1-2 people) but growing. I came on
| and basically acted as a junior partner with one of the
| partners who led the practice. We quickly grew that to
| supporting ~100 deals/year. The company wasn't strategic
| about the work (they wanted large scale IT strategy gigs), so
| we split off and I start my own firm that focused solely in
| on IT/Tech DD. I then sold that company to my biggest
| competitor. I'm now an MD/Executive at that firm. My
| experience with hands on development, owning/operating a
| business, M&A, mix of enterprise software + implementation,
| and consulting (this can't be understated, there is a ton of
| value in knowing "how to be a consultant") is probably what
| really helped me excel in this space. Oh and now that I've
| sold a company myself, I have even more perspective :)
|
| Typical person:
|
| There are usually two types of personas that fit well: career
| consultants in tech M&A (think E&Y, West Monroe, KPMG, etc.)
| and operational leaders (e.g. seasoned CTOs, VP of
| Engineering, Head of Product, etc.). People who have done
| both are IDEAL. Personally I look for "athletes" or T-Shaped
| people. You need to be able to get very technical and then
| translate this to a financial person who doesn't know the
| difference between Java and JavaScript, which is a very
| unique skill in itself.
|
| P.S. I have a huge demand Product people (market + technical)
| who want to help do Product Due Diligence + Product Strategy
| consulting. Please reach out if you're interested.
| kinnth wrote:
| AMA Question - Does a process like this help you make better
| acquisitions, or is there still an art in picking the right
| startup at the right time for a business?
| mbesto wrote:
| My firm doesn't acquire the companies themselves, we work
| with companies (like Gitlab) or private equity firms who
| acquire businesses to help them understand the technology. So
| our clients pick the startup and they usually have a thesis
| for acquisition. During diligence it's their opportunity to
| confirm or deny that thesis, and as an objective, third party
| set of expert eyes we can help them do that.
| [deleted]
| jacquesm wrote:
| If you want to do an AmA you should probably do some
| answering... I don't feel like hijacking your thread but
| really, those are important questions.
| weird-eye-issue wrote:
| You posted this 1 hour after he originally posted? Yikes,
| chill out
| mbesto wrote:
| More than happy for you to answer as well - I respect your
| opinion on this topic.
|
| P.S. - don't really appreciate the snarky "you should do some
| answering"... as a fellow busy professional, I'm answering
| when I have the time to do so.
| sieabahlpark wrote:
| [dead]
| jacquesm wrote:
| It wasn't snarky, more that if you're going to do an AmA
| that kind of puts the ball in your court and you really
| should use the opportunity because if you don't have time
| now then it might be better to do this as a separate 'Ask
| HN' or something to that effect.
|
| This subject is very dear to a lot of the HN crowd and of
| course you as the initiator of that process should get the
| first shot at answering these questions, they are all super
| relevant and very practical. You might even want to do a
| formal write-up of the answers you get in a blog post.
| esskay wrote:
| It might not have intended to be snarky but theres really
| only one way you can take "you should probably do some
| answering".
| jacquesm wrote:
| HN threads can die rather quickly and it would be a real
| loss of an opportunity. But fine, next time I'll just
| STFU.
| ryanSrich wrote:
| What does your company charge for standard B2B SaaS acquisition
| technical DD?
| mbesto wrote:
| Unfortunately, I can't disclose that, but I can tell you what
| market rates tend to be. I've seen firms in this space charge
| anything from $10k to $150k per deal. The lower end tends to
| be the "one man shop" and the larger end tends to be more
| established advisory firms who work on large and or complex
| deals.
| ramraj07 wrote:
| That sounds... cheap. Like that's less than the monthly
| take home for a single non descript engineer.
| mbesto wrote:
| Quite the contrary. The projects last 2~3 weeks.
| ryanSrich wrote:
| Yeah I think having an hourly rate would have been more
| useful, but I appreciate their reply regardless.
|
| I've done DD for a small SaaS acquisition. But from the
| sell side. It was a decent amount of work providing
| access, diagrams, answering questions, etc. I would think
| anywhere from $150-$300/hour depending on the deal size.
| eddsh1994 wrote:
| Where are you making $150k a month and are you hiring?
| weird-eye-issue wrote:
| > the larger end tends to be more established advisory
| firms who work on large and or complex deals.
| yamtaddle wrote:
| I'd assume the higher end includes the auditing company
| holding a pile of compliance certs. Those can be pretty
| expensive to pick up.
| Cthulhu_ wrote:
| Do you have an example of your work? I'm curious what a report
| looks like, having done only a couple of 'code reviews' myself
| (that is, I got a codebase and three days to write a report on
| how it could be improved, not very formal at all).
| twodave wrote:
| I've been a part of a few of these, and it really just
| depends. Overall, though, the report will break down the
| company into a bunch of different categories (and not just
| from a code/tech stack standpoint). Sometimes you'll get a
| point-rating (1-10 or whatever) or a market-based rating
| (e.g. degrees worse, comparable or better than their
| competition in a category).
|
| The audit may encompass anything from code quality, technical
| debt, tech stack, architecture, infrastructure, to the
| product roadmap, licensing of dependencies, corporate
| structure, hiring/retention of talent, etc. It really just
| depends on what the company paying for the DD asks for (which
| could be either side, and that also matters a lot).
|
| Each category in the final report will have a summary, a
| score, notes about risks/opportunities, suggestions on how to
| improve, what things are strengths, etc. It can be really,
| really long, and often it's broken up and worked on by
| multiple people based on their area(s) of expertise. Usually
| you'll see a high-level summary chart at the end of the
| report that just kind of puts everything in front of you.
| mbesto wrote:
| This is a very good summary of what deliverables look like.
| mbesto wrote:
| I'd love to share this, but unfortunately our reports belong
| to our clients so it would be really hard for to disclose an
| example to the public.
| NineStarPoint wrote:
| Do you know of any documents similar to what you do that
| have been disclosed to the public, or is this a sub-
| industry that us completely opaque to outsiders?
| code_runner wrote:
| It would be interesting if you did some open source project
| of sufficient size or something. (Unless it's not a one-to-
| one or something)
| [deleted]
| coreyrab wrote:
| AMA question: I've never personally been through this process,
| but I assume go-to-market DD is typically part of the process.
| Are there specialized firms that handle that side of the
| equation?
| mbesto wrote:
| Can you be more specific? Do you mean like doing a DD on the
| product and sales strategy of the company that is being
| acquired?
| wslh wrote:
| Excellent topic, my company also does technical due diligence.
| Even so, beyond acquisition, regarding investments we see that
| founders networking and promises take over technical
| capabilities. Not the same for pure acquisitions. Shameless
| plug: [1]
|
| It would he great if the HN community could comment more about
| this topic beyong the Gitlab's article.
|
| [1] Fundamental Analysis of Web3 Technologies:
| https://blog.coinfabrik.com/fundamental-analysis-of-web3-tec...
| rfrey wrote:
| Wow - I can see why Paul Graham at one point talked about how
| exploring an acquisition can kill a company. Even at the
| "preliminary diligence" stage, a small company will have invested
| at least a month of the founder's time AND basically given away
| the keys to the kingdom - all their schemas, processes, customer
| lists, and contracts.
|
| I know there would be non-disclosures in place, but it's easy to
| imagine a company less scrupulous than Gitlab basically cratering
| a potential competitor without the resources to go after them in
| court.
| bberenberg wrote:
| Yes there is a risk of this. But, with modern tooling, you
| don't need to do this to accomplish the same goals. It's not
| hard to figure out the high level approach of what someone else
| is doing. It's not hard to figure out a significant number of
| their customers. There are entire companies that exist to
| answer these questions for you. Ultimately, if you're looking
| to sell your company, you will have to trust the acquirer. This
| isn't a GitLab thing, it's just the name of the game. I wrote a
| bit about selling my company a year ago [1] and it was similar,
| except a lot of the diligence happened post LOI / Term Sheet.
| In hindsight, I kind of wish it had happened earlier.
|
| [1] https://www.nothingeasyaboutthis.com/lessons-from-
| selling-a-...
| tptacek wrote:
| It's a lot of time, but it's probably more important that it's
| psychologically destructive. As soon as you've invested any
| meaningful time into an acquisition discussion, it becomes very
| difficult to manage the company as a going concern and to make
| good long-term decisions about it. You're explicitly
| contemplating ending the company.
|
| You mostly don't need the "don't talk to corpdev" advice once
| you've found product/market fit, unit profitability, whatever;
| it's more obvious whether the discussion is a waste of time or
| not. But early on, it's an especially hazardous thing to do,
| because you're not anchored to a specific conception of how
| your business is going to operate.
| rfrey wrote:
| That's a super interesting point... even if you're fine
| financially and the acquirer doesn't sabotage you, you've
| fundamentally damaged the company by exploring acquisition.
|
| Like if somebody goes from working hard on a marriage to
| seriously investigating divorce. Even if they decide divorce
| was too expensive or whatever, they're never getting back to
| even the problematic state they were in before they called a
| lawyer.
| tptacek wrote:
| To make matters worse, corp dev people are absolutely aware
| of the dynamics --- they're more aware of them than you
| are, because this is their entire job, where you might
| engage with it once or twice in a whole career --- and are
| selected for their expertise at manipulating the dynamic.
| They will, if they're seriously targeting you, deliberately
| bait a hook and keep you on the line long enough for
| walking away from a deal to be especially painful.
|
| I think Paul Graham pretty much has this topic locked up
| and can't see how you'd express it better.
| fatnoah wrote:
| Having gone through an acquisition by a different company, I
| can say that this process almost exactly matches the process I
| went through. It was definitely a lot of work that ate up tons
| of time. It also wasn't something that could be discussed with
| most of the company, so now you add a few months of "acting
| funny" to the mix and it's a challenge and a half.
| akamia wrote:
| I was a lead at a startup that was acquired and the acquisition
| process would have probably sunk us if the acquisition had not
| gone through.
|
| We were in the middle of raising our next round when the offer
| came through. The founders and the board decided to accept the
| offer but it was still contingent on due diligence. While going
| through the due diligence process all funding conversations had
| to stop. Luckily we were small so the due diligence process
| only took 2 months but we had to tighten our belts. If the
| acquisition had fallen through, we would've been in real
| trouble because we burned 2 months of cash and would have
| needed to line up funding quickly.
| ignite wrote:
| I don't know if this is still a common thing, but this
| definitely used to happen.
| iamdamian wrote:
| It seems that Amazon did something similar under the guise of
| becoming an investor:
| https://news.ycombinator.com/item?id=23929044
| mbesto wrote:
| 100% true. So people are aware, even if you get to an LOI, then
| there is usually an established close period (right now it's
| usually 30-90 days). That close period is intense and can
| absolutely derail the energy of the company.
| ericb wrote:
| Pretty cool that they shared the process. A couple things that
| seem interesting to me:
|
| * Giving the acquirer the cap table early on seems to go against
| the advice I've seen.
|
| * This is a _ton_ of time investment for a company that has no
| idea if an offer will be forthcoming, or if it would be in a
| ballpark where a deal would happen?
|
| The acquiree is supposed to go through 12 stages of diligence a
| code review, detailed financials, employee review, give out their
| roadmap, customers, vendors, cap table, source code, financial
| assets all before seeing any hint of what the offer will be or
| whether there will be one?
|
| Is that right? Wouldn't getting an idea of whether you're in the
| same neighborhood be sensible before demanding so much?
| mbesto wrote:
| I think this is more of a technical/operational process, and
| less about the financial/legal one. Typically there is a "LOI"
| (Letter of Intent) that kicks off the DD process. That
| stipulates the acquisition price, any key terms (cash vs
| stock), etc.
| ericb wrote:
| I agree. It seems like they are trying to be transparent and
| detailed, though, and I don't see that in their list, and the
| negotiations only appear around step 13?
| jacquesm wrote:
| > Giving the acquirer the cap table early on seems to go
| against the advice I've seen.
|
| Why?
|
| Captables are for the most part just process documents, you
| need to know who has which quantity of shares to be able to put
| a proposal for a deal on the table. If you don't know who holds
| the shares you may not even be able to make a proposal at all,
| and you may not be able to verify that the person that makes
| the offer to sell has the right to do so.
| ericb wrote:
| I think the reasoning is something like, when I buy a car, I
| don't base the price I'll pay on the cost of the raw
| materials.
|
| It also lets them craft a minimal price deal, and do things
| like split out different shareholders based on what they'll
| likely accept.
|
| Not particular to the cap table, but the same with the
| financials here. If gitlab sees they have only one month's
| runway, why wouldn't they lowball?
|
| Generally speaking, if gitlab sees 40 million in revenue
| potential, shouldn't that be how they craft what they offer?
|
| There's probably a distinction here between "selling" your
| business, and "being acquired."
| jacquesm wrote:
| Sure, but it helps if you can show who actually owns the
| car. And a captable is pretty much just that: a division of
| who owns which chunk of the company. No need to disclose
| what they paid for it, that's not the acquirers' business
| anyway.
| bombcar wrote:
| Wouldn't a start-up that is considering being acquired (or
| raising) already have most of this available?
| jacquesm wrote:
| Depends on who starts the process. If the acquirer starts it
| then there may well be nothing at all.
| moneywoes wrote:
| Seems like they could just steal a lot of info and then build
| their own version through this process
| cs02rm0 wrote:
| Does seem odd to expect to share code early and a risk to
| share it with any interested party.
|
| I mean, it's someone else's code, your engineers are going to
| say it's rubbish, it needs a full rewrite and throwing away,
| warn us up front before you even think about acquiring such
| terrible code, etc. But if it's a built a company to the
| point of raising sufficient revenue/profit it's surely good
| enough.
| jacquesm wrote:
| It is. Normally you only do that after you agree on the
| terms and that means there is a deal unless something
| horrible is found during DD. And if your code is terrible
| simply disclose it then likely the requirement will go
| away. But if you claim it is super good but you only have
| juniors on staff you can expect to be quizzed.
| jacquesm wrote:
| Yes, this happens. So be _very_ much on your guard about this
| and make sure that you trust whoever you talk to and if you
| can 't trust them then you can ask a trusted party to do the
| review for you and pass that to whoever claims to be
| interested.
|
| There are many variations to this kind of 'vendor dd', you
| can prepare it beforehand or you can push to have the process
| modified until it is to your liking depending on how
| desirable you are.
| WJW wrote:
| Not that that never happens, but engineering time is not
| cheap even at Gitlab scale. Even if you manage to recreate
| the product based on the insider info it's still a risky
| process; new products fail all the time, especially if they
| are new entries in an already filled market.
|
| It's much quicker and often not that much more expensive
| (after you tally up all the engineering and marketing costs
| and adjust for the risk of failure) to acquire a company that
| already has a working product, customers, marketing,
| documentation and usually you get a team of domain experts
| included in the purchase.
| formercoder wrote:
| If there's one thing you learn quickly about doing M&A it's
| everyone does a lot of work that might not result in a
| transaction.
| jacquesm wrote:
| That gets expensive. A typical VC that does a bunch of these
| without being able to follow through will rapidly find their
| management fees exhausted (because that's where quite a few
| of them fund failed DDs from, a typical DD budget is anywhere
| from 150K to 500K depending on the deal size, that includes
| legal, financial, technical, commercial, possibly an
| evaluation of the founders and whatever else is deemed
| necessary).
| paulsutter wrote:
| > Giving the acquirer the cap table early on seems to go
| against the advice I've seen
|
| The cap table tells a story about the company. For starters it
| identifies the decisionmakers. More importantly, a hairy
| complex cap table says an acquisition process may be difficult
| and unpredictable. A straightforward cap table is like a well
| maintained roof on a house. It doesn't prove that the rest of
| the company is in order, but its highly correlated
|
| Start by sending a summary cap table of major holders with the
| breakdown among classes of stock
| Cthulhu_ wrote:
| > This is a ton of time investment for a company that has no
| idea if an offer will be forthcoming, or if it would be in a
| ballpark where a deal would happen?
|
| But the work can be reused for other candidates, and... this is
| about multi-million deals, the work will pay itself off.
|
| I heard about a financial guy working his ass off (nights,
| weekends) for weeks if not months on end on getting part of the
| company acquired or sold off; in the end the deal was worth
| EUR100M, and I'm confident he owned a significant chunk of the
| part sold. I wouldn't mind working weekends / evenings for a
| while if it was for a "you can retire" sum of money.
___________________________________________________________________
(page generated 2023-02-20 23:00 UTC)