Imagine it’s the year 1890 at Standard Oil and they have a building full of filing clerks.
It’s run by the great John D Rockefeller, of which you can read more in the fantastic biography Titan. He’s a stickler for accurate accounting at all times.
Now they decide to buy a batch of barrels for all their oil.
- one clerk runs down to the cabinet with a file for all the items SO buys.
- another cross-references each item and fetches the files of the vendors for each of those items
- another cross-references with past invoices to get the most recent price for each item
- another gets a list of locations SO uses to store barrels
Now the purchasing manager looks at all this and decides which barrels to buy, from which vendor, how many, and where its getting delivered. So he writes out a purchase order / PO.
So back to the clerks:
- one runs along to file the PO in the PO filing cabinet. Remember, uncle John is watching and he wants to go to any cabinet or any manager at any time and get up-to-date details of what's going on.
- another one goes to the Items cabinet, finds the barrels we ordered, and notes on them that a PO was issued for this many barrels on such and such a date.
- one actually sends a copy of the PO to the vendor.
Skipping over some steps for simplicity, the barrels arrive one day with their invoice attached.
An Invoice! Now the army of clerks swing back into action. They get their guy at the warehouse to send them the original invoice that came stapled to the barrels. Then:
- one runs to the PO cabinet, finds the PO that was issued, marks it as done, and writes the invoice number on it.
- another one runs to the accounting department. There they make the double-entry bookkeeping entries to account for the money that is now owed to the vendor, and for the inventory value that has gone up.
- another one runs to the vendor cabinet and records the purchase on their file
- another one goes to the inventory cabinet and files a record updating the inventory balance for the barrel item
- someone files a copy of the invoice for future reference
Eventually we pay the invoice:
- a clerk keeps an eye on the payment terms for this and other vendors and calculates how much cash we have to send to each vendor each month
- another runs around to each paid invoice marking them as paid
- another one actually writes the cheques and mails them off
- someone has to tell the accounting department how much money we just paid, to which vendors, out of which bank accounts
Things get fun when these barrels eventually get sent to a production facility and filled with oil. Now the clerks have to do the correct filings to destroy the barrel items along with a quantity of oil, and create a new filled-barrel item. The cost of this depends on all of the cost of the barrel item, the oil, the labour, and some other things, all of which is determined using past entries.
This is a toy example and the complexity spirals from here. For example another invoice can arrive from the people who transported the barrels. Depending on your CFO, or the current accounting laws, you might want to include that in the cost of the barrels, or record it as a business expense.
You might have different departments who do their accounting separately, so now each transaction has to be split correctly. You might want to track the hourly rates of each employee and factor that into the cost of each finished-barrel item, and also tracking what everybody should get paid.
Add to this any idiosyncratic business rules stemming from management decisions, laws, unique physical constraints, or whatever.
An ERP system is all of these cabinets and their rules put into a relational database with a front-end.
I love payback period, it's a great metric. But it's easy to take it too literally. It's meant to be a tool to help you make prioritization decisions ("what if we do this instead of that"), but people often use it as a management report ("we did this; here's the verdict").
Here's a SaaS example: if it costs you $1000 to acquire a customer that pays you $100/month, the PBP is 10. That doesn't sound amazing. But you have options! If you give the customer a 20% discount to pay annually, they're now paying you ~$1000 upfront, for a PBP of 0. Tweak the numbers slightly and you can get a negative payback period. Suddenly your "capital inefficient" business has a big flywheel without the need for outside capital.
It's easy to think decreasing acquisition costs is what you need to do in the current market (and believe me, that's not a bad idea!), but that's the denominator. There's also a numerator - how much cash you bring in, and how quickly - that matters just as much. It's cash flow that matters, not profit.
Personally after using docker compose since it came out I’m excited to see the evolution of local Kubernetes development. I’d scrap even dealing with trying to make something as limited as docker compose do what you want. I’d focus on moving towards local Kubernetes development.
This will bring you closer to the deployment stack if you are deploying to Kubernetes. Then also let you leverage tools like kustomize to dry out your configurations.
There are some great projects like tilt, devspace, skaffold, etc that help facilitate deving on a local or remote cluster.
As far as configuration management that can be as simple as cascading kustomize configs or helm. Then leveraging something like vault. The point really is, if you start with Kubernetes you have way more flexibility with tooling and options to do whatever the heck you want.
Shameless plug I recently started a series on local Kubernetes development. It covers some of this with tilt and more. If you would like a specific thing covered here I can add an installment to it. https://youtube.com/watch?v=Nj55RDVwrIE&si=EnSIkaIECMiOmarE
- You can post it in places where people might be interested, like HN, Reddit, ProductHunt, Twitter, forums, etc. (carefully and thoughtfully, so it doesn't come across as spam).
- You can email it to people who might be interested (very carefully and thoughtfully, with an individually tailored message, so it doesn't come across as spam).
- You can email it to tech journalists, bloggers, and other people with influence, hoping that they'll help you publicize it.
- You can email it to a pre-existing audience you've built up if you're fortunate enough to have one.
- You can buy ads.
- You can produce content or do cross-promotion (which you say you don't want to do--it can work but certainly isn't required).
If none of the above is getting any traction, most likely the product and/or pitch isn't compelling enough and you should iterate on that before investing more time or money into marketing.
But for anything non-trivial, that app that does everything person A needs doesn't do what person B needs, and vice versa. It mostly does what person C needs, who is a whiteboard made subset of the most used features and doesn't match anyone.
It's not just UNIX-like flexibility, it's human uniqueness, and the uniqueness of the tasks they perform and the ideas they have. It's also the difference between owning and knowing how to use a tool, versus renting someone to do it for you who might help you today, but could rob or hurt you tomorrow.
Just consider how we spend decades to teach new humans to read and write as well as they can learn it, versus just giving them a bunch of emoticons to signal when they're hungry or sleepy or bored. Because we expect them to become full peers, and architects of their world, responsible for the next generation, not just consumers picking options others prepared for them. And we don't care if they want that, because we know what they don't know, yet. We base our judgement on the information we have, not the information they lack.
Making an exception for computer literacy just because it is hard (as if language and reading and writing aren't until you get used to them) set us on a terrible path.
I own several Texas BBQ restaurants. We have a pitmaster but here are the things I know:
1. Not all beef/cattle are created equally. You must start with a high quality brisket. Just because it is a prime grade brisket is not enough. We tasted brisket from many farms and we centered on Creekstone Farms.
2. Not all smokers are created equally. Test the extremes including low-slow (12-15 hours) vs fast-high (8 hours). We found offset is good for low-slow, but gas powered is better for fast-high.
3. Not so secret: you must rest the brisket for 12 hours in a warmer after it is finished cooking. This gets the fat rendered inside, so you can get those grooves / mountains and peaks within the meat. This also achieves the most tender brisket.
4. Before wrapping with butcher paper, we put beef tallow on the brisket. This creates a juicier product for us.
5. Injecting and/or putting brisket slices in broth never worked for us. Instead of tasting like juicy brisket, it tasted like "brisket and broth".
6. We trim a lot to get a more even brisket with consistent height, and use trimmings for other products. Consistent height means your flat lean side won't dry out by the time the fatty point side is cooked.
It’s run by the great John D Rockefeller, of which you can read more in the fantastic biography Titan. He’s a stickler for accurate accounting at all times.
Now they decide to buy a batch of barrels for all their oil.
- one clerk runs down to the cabinet with a file for all the items SO buys.
- another cross-references each item and fetches the files of the vendors for each of those items
- another cross-references with past invoices to get the most recent price for each item
- another gets a list of locations SO uses to store barrels
Now the purchasing manager looks at all this and decides which barrels to buy, from which vendor, how many, and where its getting delivered. So he writes out a purchase order / PO.
So back to the clerks:
- one runs along to file the PO in the PO filing cabinet. Remember, uncle John is watching and he wants to go to any cabinet or any manager at any time and get up-to-date details of what's going on.
- another one goes to the Items cabinet, finds the barrels we ordered, and notes on them that a PO was issued for this many barrels on such and such a date.
- one actually sends a copy of the PO to the vendor.
Skipping over some steps for simplicity, the barrels arrive one day with their invoice attached.
An Invoice! Now the army of clerks swing back into action. They get their guy at the warehouse to send them the original invoice that came stapled to the barrels. Then:
- one runs to the PO cabinet, finds the PO that was issued, marks it as done, and writes the invoice number on it.
- another one runs to the accounting department. There they make the double-entry bookkeeping entries to account for the money that is now owed to the vendor, and for the inventory value that has gone up.
- another one runs to the vendor cabinet and records the purchase on their file
- another one goes to the inventory cabinet and files a record updating the inventory balance for the barrel item
- someone files a copy of the invoice for future reference
Eventually we pay the invoice:
- a clerk keeps an eye on the payment terms for this and other vendors and calculates how much cash we have to send to each vendor each month
- another runs around to each paid invoice marking them as paid
- another one actually writes the cheques and mails them off
- someone has to tell the accounting department how much money we just paid, to which vendors, out of which bank accounts
Things get fun when these barrels eventually get sent to a production facility and filled with oil. Now the clerks have to do the correct filings to destroy the barrel items along with a quantity of oil, and create a new filled-barrel item. The cost of this depends on all of the cost of the barrel item, the oil, the labour, and some other things, all of which is determined using past entries.
This is a toy example and the complexity spirals from here. For example another invoice can arrive from the people who transported the barrels. Depending on your CFO, or the current accounting laws, you might want to include that in the cost of the barrels, or record it as a business expense.
You might have different departments who do their accounting separately, so now each transaction has to be split correctly. You might want to track the hourly rates of each employee and factor that into the cost of each finished-barrel item, and also tracking what everybody should get paid.
Add to this any idiosyncratic business rules stemming from management decisions, laws, unique physical constraints, or whatever.
An ERP system is all of these cabinets and their rules put into a relational database with a front-end.