Maybe easiest to explain from a software perspective.

So if you build a SaaS app, your company will incur a number of costs. You need to pay AWS for hosting, your support team, your sales team, your annual team retreat to Mexico, etc.

When you start measuring your profitability you then will separately measure the profitability of your product vs. your business.

The profitability of the product is your gross margin - essentially your revenue minus your cost of goods sold (COGS). Not all of your business expenses fall into here - only the costs that directly relate to supporting the product.

So… - Your annual team retreat won’t hit your gross margin: this cost isn’t essential to supporting the product - Your AWS costs will hit your gross margin (if you turned off AWS tomorrow, your product stops working) - Your Slack bill does not hit gross margin - Your product & engineering team normally doesn’t hit gross margin, but DevOps does (because DevOps is seen as essential to supporting the product while R&D is not)

Now in reality it does get a bit more messy. Businesses might allocate a % of engineering costs to GM to account for essential maintenance and bugfixes.

So the way to look at it is: what costs are essential to the continued delivery of the product and what are nice-to-have?

And then operating margin essentially considers all of the non capital costs. It’s a more comprehensive view of all the businesses revenue and costs.

For a smaller business it’s very normal for operating margin to be razor thin or even negative. Because just one or two engineers could cost more than your entire revenue.

But this entire concept is why software companies have historically been able to be unprofitable for so long. A business that’s losing a ton of money every month might only be losing that money because it’s investing very heavily in R&D. Or maybe it just moved into a new

As you scale the relative impact of a lot of those costs will go down significantly - e.g. your engineering team cost will stop being 300% of your revenue and will start being 20% (you don’t hire engineers linearly with growth).

So the theory is that if you can find a software that has: - a big market - great gross margin

Then with just some upfront cash investment you can provide the business enough runway to grow the revenue to the point where the impact of some of these expenses becomes very small. At a certain scale, a product with 50%+ gross margin will be producing so much cash that it can pay for the rest of your operational expenses without further investment.

You will need to sacrifice something. If the regulations become more restrictive, one of the following needs to change:

- cost (laptops getting more expensive) - quality (laptops getting less powerful / smaller) - time (manufacturers have a long grace period before they need to implement the regulations, to allow technology to catch up)

The EU always implements this kind of legislation with grace periods - obviously, no step functions.

I have a lot of experience with this. Happy to have a call to give you some tips - my email address is in my profile.

I'm interested, can you email me (address in profile)

Yes this is the same for me. I’ve shifted my programming style so now I just write function signatures and let the AI do the rest for me. It has been a dream and works consistently well.

I’ll also often add hints at the top of the file in the form of comments or sample data to help keep it on the right track.

Here's one I wrote the other day which took a long time to get right. I'm curious on how well your AI can do, since I can't imagine it does a good job at it.

  # Given a data set of size `size' >= 0, and a `text` string describing
  # the subset size, return a 2-element tuple containing a text string
  # describing the complement size and the actual size as an integer. The
  # text string can be in one of four forms (after stripping leading and
  # trailing whitespace):
  #
  #  1) the empty string, in which case return ("", 0)
  #  2) a stringified integer, like "123", where 0 <= n <= size, in
  #   which case return (str(size-int(n)), size-int(n))
  #  3) a stringified decimal value like "0.25" where 0 <= x <= 1.0, in
  #   which case compute the complement string as str(1 - x) and
  #   the complement size as size - (int(x * size)). Exponential
  #   notation is not supported, only numbers like "3.0", ".4", and "3.14"
  #  4) a stringified fraction value like "1/3", where 0 <= x <= 1,
  #   in which case compute the complement string and value as #3
  #   but using a fraction instead of a decimal. Note that "1/2" of
  #   51 must return ("1/2", 26), not ("1/2", 25).
  #
  # Otherwise, return ("error", -1)

  def get_complement(text: str, size: int) -> tuple[str, int]:
    ...

For examples:

  get_complement("1/2", 100) == ("1/2", 50)
  get_complement("0.6", 100) == ("0.4", 40)
  get_complement("100", 100) == ("0", 0)
  get_complement("0/1", 100) == ("1/1", 100)

Some of the harder test cases I came up were:

get_complement("0.8158557553804697", 448_525_430): this tests the underlying system uses decimal.Decimal rather than a float, because float64 ends up on a 0.5 boundary and applies round-half-even resulting in a different value than the true decimal calculation, which does not end up with a 0.5. (The value is "365932053.4999999857944710")

get_complement("nan", 100): this is a valid decimal.Decimal but not allowed by the spec.

get_complement("1/0", 100): handle division-by-zero in fractions.Fraction

get_complement("0.", 100): this tests that the string complement is "1." or "1.0" and not "1"

get_complement("0.999999999999999", 100): this tests the complement is "0.000000000000001" and not "1E-15".

get_complement("0.5E0", 100): test that decimal parsing isn't simply done by decimal.Decimal(size) wrapped in an exception handler.

Also, this isn't the full spec. The real code reports parse errors (like recognizing the "1/" is an incomplete fraction) and if the value is out of range it uses the range boundary (so "-0.4" for input is treated as "0.0" and the complement is "1.0"), along with an error flag so the GUI can display the error message appropriately.

I suspect certain domains have higher performance than others. My normal use cases involve API calls, database calls, data transformation and AI fairly consistently does what I want. But in that space there are very repeatable patterns.

Also with your example above I probably would break the function down into smaller parts, for two reasons 1) you can more easily unit test the components; 2) generally I find AI performs better with more focused problems.

So I would probably first write a signature like this:

  # input examples = "1/2" "100" "0.6" "0.99999" "0.5E0" "nan"
  def string_ratio_to_decimal(text: str) -> number

Pasting that into Claude, without any other context, produces this result: https://claude.site/artifacts/58f1af0e-fe5b-4e72-89ba-aeebad...

> I probably would break the function down into smaller parts

Sure. Internally I have multiple functions. Though I don't like unit testing below the public API as it inhibits refactoring and gives false coverage feedback, so all my tests go through the main API.

> Pasting that into Claude, without any other context

The context is the important part. Like the context which says "0.5E0" and "nan" are specifically not supported, and how the calculations need to use decimal arithmetic, not IEEE 754 float64.

Also, the hard part is generating the complement with correct formatting, not parsing float-or-fraction, which is first-year CS assignment.

> # Handle special values

Python and C accept "Infinity" as an alternative to "Inf". The correct way is to defer to the underlying system then check if the returned value is infinite or a NaN. Which is what will happen here because when those string checks fail, and the check for "/" fails, it will correctly process through float().

Yes, this section isn't needed.

> # Handle empty string

My spec says the empty string is not an error.

> numerator, denominator = text.split("/"); num = float(numerator); den = float(denominator)

This allows "1.2/3.4" and "inf/nan", which were not in the input examples and therefore support for them should be interpreted as accidental scope creep.

They were also not part of the test suite, which means the tests cannot distinguish between these two clearly different implementations:

  num = float(numerator)
  den = float(denominator)

and:

  num = int(numerator)
  den = int(denominator)

Here's a version which follows the same style as the linked-to code, but is easier to understand:

    if not isinstance(text, str):
        return None
    
    # Remove whitespace
    text = text.strip()
    
    # Handle empty string
    if not text:
        return None

    # Handle ratio format (e.g., "1/2")
    if "/" in text:
        try:
            numerator, denominator = text.split("/")
            num = int(numerator)
            den = int(denominator)
            if den == 0:
                return float("inf") if num > 0 else float("-inf") if num < 0 else float("nan")
            return num / den
        except ValueError:
            return None

    # Handle regular numbers (inf, nan, scientific notation, etc.)
    try:
        return float(text)
    except ValueError:
        return None

It still doesn't come anywhere near handling the actual problem spec I gave.

I've built a couple of experiments using it so far and it has been really interesting.

On one hand, it has really helped me with prototyping incredibly fast.

On the other, it is prohibitively expensive today. Essentially you pay per click, in some cases per keystroke. I tried to get it to find a flight for me. So it opened the browser, navigated to Google Flights, entered the origin, destination etc. etc. By the time it saw a price, there had already been more than a dozen LLM calls. And then it crashed due to a rate limit issue. By the time I got a list of flight recommendations it was already $5.

But I think this is intended to be an early demo of what will be possible in the future. And they were very explicit that it's a beta: all of this feedback above will help them make it better. Very quickly it will get more efficient, less expensive, more reliable.

So overall I'm optimistic to see where this goes. There are SO many applications for this once it's working really well.

I guess I'm confused there's even a use case there. It's like "let me google that for you". I mean Siri can return me search results for flights.

A real killer app would be something that is adaptive and smart enough to deal with all the SEO/walled gardens in the travel search space, actually understanding the airlines available and searching directly there as well as at aggregators. It could also be integrated with your Airline miles accounts and all suggested options to use miles/miles&cash/cash, etc.

All of that is far more complex than .. clicking around google flights on your behalf and crashing.

Further, the real killer app is that it is bullet proof enough that you entrust it to book said best flight for you. This requires getting the product to 99.99% rather than the perpetual 70-80% we are seeing all these LLM use cases hit.

The airline booking + awards redemption use case is a mostly solved problem. Harcore milage redemption enthusiasts use paid tools like ExpertFlyer that present a UI and API for peeking into airline reservation backends. It has a steep learning curve, for sure.

ThePointsGuy blog tried to implement something that directly tied into airline accounts to track milage/points and redemption options, but I believe they got slapped down by several airlines for unauthorized scraping. Airlines do NOT like third parties having access to frequent flier accounts.

While the strategy to find good deals / award space is a solved problem, the search tools to do so aren't. Tools like ExpertFlyer are super inefficient: it permits you to search for maximum one origin + one destination + one airline per search. What if you're happy to go to anywhere in Western Europe? Or if you want to check several different airlines? Then all of a sudden your one EF search might turn into dozens. And as you say, pretty much all of the aggregator tools are getting slapped down by airlines so they increasingly have more limited availability and some are shutting down completely.

And then add the complexity that you might be willing to pay cash if the price is right ... so then you add dozens more searches to that on potentially many websites.

All of this is "easy" and a solved problem but it's incredibly monotonous. And almost none of these services offer an API, so it's difficult to automate without a browser-based approach. And a travel agent won't work this hard for you. So how amazing would it be instead to tell an AI agent what you want, have it pretend to be you for a few minutes, and get a CSV file in your inbox at the end.

Whether this could be commercialised is a different question but I'm certainly going to continue building out my prototype to save myself some time (I mean, to be fair, it will probably take more time to build something to do this on my behalf but I think it's time well spent).

Yes I think this points to the need for adaptiveness which remains humans edge.

We don't need PBs of training data, millions of compute, and hours upon hours of training.

You could sit down a moderately intelligent intern as a mechanical turk to perform this workflow with only a few minutes of instruction and get a reasonably good result.

Ah, but I think you're overlooking one major factor. Convenience. A lot of the spontaneous stuff we do ("hey why don't we pop down to x tomorrow?", or "do you fancy a quick curry?") are things you're not going to book with a Turk. BUT you definitely would fire up a quick agent on your way to the shower and have it do all the work for you while you're waxing your armpits. :) Agentic work is starting super slow, but once the wrinkles are worked out, we'll see a world where they're doing a huge amount of heavy lifting for the drudge stuff. For an example see Her - sorry! :)

Underrated comment.

Yes, that seems to be the larger challenge. The search tools I have used will work for a while until they don't. Real cat & mouse game.

Hence the "adaptive" part of my comment.

It really needs to be a client side agent.

Haiku 3.5 wol be here soon, and will before long support tool use and vision, so that should help a lot with cost.

It’s running in the browser but connected to a VM, right? When you say crashed, what did it do?

time is also a huge factor on this one, should be a nice metric

god the future is here haha

As somebody who works in tech in the UK, some of my thoughts:

- I don’t really see senior engineering IC salaries below GBP 100k

- “Head of” roles are materially higher than IC roles, mid-to-high-100s.

- All of my experience is London-based so there is likely a premium compared to a market like Manchester

- There are a lot of other factors, so don’t take this as gospel, but unless it you are in a hot market like AI, your business is probably getting a 5-20x multiple on ARR - the fact that your business growth is so impressive and near profitable makes the top end of that achievable. If the primary goal is to get to 10M and the founders want to sell “sooner than later” then you probably need to mentally prepare for an exit of around 50-200M, or an outcome for you of 100-400k. The math changes significantly if the business doesn’t plan to exit for longer. But say you got 200k, does that make up for several years of below market salary and risk?

- You’ve been at the biz for 4 years? I know you say there’s no vesting schedule but usually equity vesting happens over 4 years, so you should be due for another grant if the business was in line other tech businesses

If I were in your shoes I’d definitely push for more equity. You’ve been at the business long enough to be eligible for another grant. You should make sure that, if the new grant has a vesting schedule, the entire grant automatically vests as part of an acquisition/change of control

And you also should be able to push a lot harder on salary, but again I can’t speak for the Manchester market.

Having been in the business for so long, and having received an offer for a role that you describe as critical to its success, the business should be willing to compensate you accordingly.

Something else to consider looking into is the business plans for profitability. It is not abnormal for profitable tech to pay bonuses. So if the business is indeed planning to be profitable, it could be a way for you to get outsized additional compensation if you’re willing to take some risk.

**And finally, it sounds like you have an unfair equity deal - largely at the company’s discretion? At this point all of your equity should be fully vested, and under EMI you should be able to exercise your options for a negligible amount of money. You should work really hard as part of your negotiation to get a better deal here for the existing equity, so you can own real shares of the business. And then you’ll loosen some of handcuffs - incentivizing the business to issue you a new grant as a retention strategy.

This is the sort of reply I was hoping for, thank you. I have a few follow ups:

- Do you have any sources for where you’re seeing salaries at 100k upwards? Anything online, or is this offline advertised roles? I’m going to need some evidence points to support my counter offer. I think a few senior salaries to solidify a low of 100s and a few head of salaries to set a benchmark will be helpful if I can find them.

- It’s not an AI business, but does leverage it. I think the 100k-400k at 0.2% isn’t a game changer, but double or triple that would be. Where are you getting your ARR multiple estimates from? I don’t doubt you, it just helps me assess my position.

Yeah I feel my equity offer is probably unfair, but didn’t know any different when accepting it sadly. Do you have any resources I could read to educate myself more about what I should be specifically asking for in a negotiation and how it works.

Sorry for the delayed reply ... feel free to email me (email address in my profile) if you have more questions

- No online sources. This is first hand data for engineers that have worked on my teams.

- Here are some resources [1] [2] [3]. During the boom a couple years ago, multiples got way higher - at the time I worked at a company that got valued at 26x. But that's not very realistic these days except for particularly hot companies. The median for SaaS is probably around 5x. But you get more points if you're growing fast, etc.

- Here are some resources [4] [5] [6]. Normally you'll see the first employee - especially the first engineering hire - get around 1%. That number drops quite quickly after the first employee. So based on your circumstances it seems you're below benchmark by around 5x, and that's further compounded by how early the founders want to exit (i.e., if you were an early employee of Instagram, then 0.2% would actually be a lot. But 0.2% of a business that wants to exit at $10M ARR doesn't make up for your risk).

[1] https://www.saasacademy.com/blog/saas-company-valuation-metr...

[2] https://feinternational.com/blog/saas-metrics-value-saas-bus....

[3] https://aventis-advisors.com/saas-valuation-multiples/

[4] https://www.hustlefund.vc/blog-posts-founders/equity-for-ear...

[5] https://www.wing.vc/docs/early-stage-hiring/how-to-determine...

[6] https://www.linkedin.com/pulse/equity-equation-mastering-fir...

I can't give you sources but personal anecdata. I concur with what the parent poster says.

Senior salaries nowadays can go from £85k to £120k depending on the company size and how important engineering is for them. Also any "Head of" confident of their value and expertise is likely on the six figures

Depending on how they measure obesity, this 1B number may be greatly overinflated. One very popular measurement is BMI which only considers height and mass, and does not consider other factors like fat vs. muscle mass, body water, etc.

For example, using BMI I am considered “obese” but I have a very high muscle mass and fairly low fat percentage (17%). So am I one of these billion people?

Very few people have high muscle mass and low fat percentage.

So technically you are counted as obese but very small fraction of people counted as obese are like you.

In my 30+ years, the vast, vast majority of obese people I see don’t look like they are obese due to muscle mass.

Sure, why not. Since BMI is used at the population level some outliers don't make it wrong.

> this 1B number may be greatly overinflated

Yeah, by the hundreds of millions of jacked folks you see everywhere /s

these days I’m often using Supabase on backend, Nextjs+Vercel frontend

it has increased my speed to market massively. I mostly work on enterprise CRUD apps so getting things like SSO and API for free on Supabase is a great time saver

and then some apps require more specialized functionality and for that I’ll leverage the AWS stack