I don’t get it. What is the point of being able to push ledger entries to this service? It isn’t really SaaS, as you’d expect to get reporting and other stuff. Plus ledger entries are pretty critical for a business and often have some regulatory requirements, which I am not sure this service could fulfil.
Thanks for taking a look planetjones! I'll try to give a worthy answer:
Amatino is trying to sit at a lower-level of the value chain than reporting, GUIs, and other layers. Amatino aims to enable others to create amazing reporting and GUIs, while charging them an extremely low price to do so.
I humbly disagree, but very much appreciate you taking the time to critique, whatsstolat! Please allow me to present a counter argument for you to consider...
In my opinion, ledger entries are the hardest part of accounting. Invoices, etc, are all supersets of double-entry accounting, and can be reduced to collections of entries if the underlying double-entry system is sufficiently robust, generic, and and capable.
Such a system should be able to, for example, recursively sum entire account trees, while transparently translating (instantly) across heterogeneous units of account (e.g. stocks, currencies, cryptos, intangibles), and do all that on any device, on any platform, at any time, anywhere on Earth, on demand.
I know this sounds crazy - Sometimes I think I am crazy! Across the world, between companies, and even within Big4 accounting firms, there are infinite ways of constructing an 'invoice' or a 'credit note'. Everyone has their preferred way, none being right or wrong.
Amatino aims to sit below that level - Allowing developers to create their accounting system their way. No compromises.
Again, I really appreciate you looking, even if you think Amatino isn't a worthwhile project. Pondering this reply was in itself a very valuable exercise for me, so thank you for taking the time to comment!
Hi everyone - I apologise for linking directly to the Amatino blog, instead of the Amatino site itself (https://amatino.io). I deleted my initial Show HN submission, having thought I posted in the wrong place, and found I could not resubmit the same URL.
The blog is probably a good place to start anyway, as it shows real development rather than my marketing-speak!
I have worked with implementations of an online digital goods marketplace built by someone who was clever but had no notion of formal accounting, ledgers, etc. Their implementation worked, but was only just barely adequate and would have been more useful with a chart of accounts. Prototyping against an API like this would have been an informative exercise for them and probably saved a lot of time.
It's an accounting environment, and every system that provides goods and/or services needs to record the transactions in an accounting system. You can either use an existing accounting system such as Quickbooks, Freshbooks, Microsoft Dynamics, but then you're writing a document to those services rather than the underlying accounts forcing you to define the sales document's properties in the accounting system. In this case you should be able to keep your documents (sales invoice/credit memo) internal to your application, and the underlying account structure. In addition using Amatino should let you create accounting schedules in your application based off the ledgers. I guess you would use Amatino where you want more control over your accounting system, and I would imagine it costs less than the full-blown commercial offerings.
Right, but recording transactions is the easy part; you can even take the schema from their docs, create a few DB tables from it, and just push to a local DB.
The reason to use a real accounting system is for the extra features (mainly reports), but I don't see them in this API, so you'd still need to export your data to one of those systems. So I'm struggling to see the advantage of pushing data to their service rather than to a local DB.
More is required than a db schema; the double entry would have to be in app logic, permission model, aging, etc. Reports are nice, but in my experience I have always had to provide additional reporting on top of what is provided by an accounting system because the business had its own requirements. I see this being useful where you are trying to avoid a traditional accounting system because you willing to provide more customization.
voidmain0001 probably put it better than I can! To add to some more cents (pardon the pun): Amatino is aimed at a lower-level of the problem than reporting, GUIs, and such. Amatino provides capabilities far in excess of a self-rolled database, and allows developers to implement their wildest GUI / reporting dreams on top.
More time spent developing awesome applications, less time spent (for example) developing logic to recursively sum accounts in multiple currencies.
Thank you for taking the time to look, icebraining! I'll try to answer briefly and not get too excited!
I see Amatino used as the unsexy, unsung, unseen double-entry data layer for other apps. Perhaps those apps are fancy GUI accounting apps like Xero, perhaps they are in-house bookkeeping systems, and so on.
Amatino saves the developers of such apps from having to develop their own double-entry systems, and provides them with a rich feature-set to draw on.
Having done some work in the area, I'd say running a service is useful but many would want code / service they could license and "own". It'd probably be worthwhile if you could make a nice Kubernetes setup to run it on prem or private vpc. Lots of banks might be really interested in that! Just my two cents. :-)
Thanks for that feedback elcritch! I think you are very right. I've often wondered if I should devote time to developing a licensed solution. I will ponder it more now...
When I worked at Xero we had lots of customers using the API to do exactly this. That said, I see value in having a api independent and agnostic from the accounting backend / saas itself, but probably more relevant for larger integrations (where the cost of switching out the integration would be extremely costly). This would also be valuable for franchises or software vendors, who could build the integration once, and then have Amatino handle the integrations to each accounting system.
The primary issue becomes ensuring the integration to the accounting systems stays high value, rather than lowest common denominator. Ie: ensure reports are usable, accounting records are in a usable format (invoices, credit notes, etc rather than a bunch of journal entries), payments are applied, bank accounts can be reconciled. If that can be nailed I feel this has value.
Wow, RileyJames, thanks so much for taking a look. It's exciting to hear your thoughts as a Xero alumni. Xero is a big inspiration for me, and I love that it has made accounting easier for so many businesses.
'Independent and agnostic from the accounting backend / says' is exactly what I'm going for, and I'm really excited to hear that you see some value in the concept. I'll take your advice to heart!
We needed this to maintain accounts for our B2B products, so we came up with https://github.com/RealImage/QLedger - we deploy the ledger as an internal service (Go+Postgres+Docker) and write a 'Bank' over it for each business model that we have (two-party / multiparty). Works great so far, and is pretty solid.
Would love feedback. We haven't yet hit the scale where postgres can't sum up the transactions in time and we need to maintain caches, but we're willing to look at ideas for that.
I agree with others that I'm not sure what a SaaS API here helps with without a lot of existing integrations/bridges to other accounting systems, data lakes/BI systems, or at the very least a good general UX that provides even basic human-readable ledgers.
Also, as an API design it seems to leak abstractions that the client should maybe not worry about. If the goal is to help applications do proper double-entry accounting, then it should provide means to add transactions without knowing the gritty details specific to entries.
Aside: I worked on API side of double entry accounting program once, long ago. In college I was an intern on Microsoft Small Business Accounting (which was renamed/rebranded towards the end of while I was there to Office Accounting). It's a shame that product was cancelled, as it was good product with proper double-entry, good reports, and a great API (even despite my major attempted improvements never making it into the product before it was cancelled ;).
It was only six months experience directly related to this field, for what little that it is worth. :) I wish you better luck than the project I had worked on. Accounting is a tough field to compete in, because everyone thinks they can do it on the back of napkins or in Excel, up until they have to pay a CPA to tell them everything that they did wrong.
If you used Amatino as the double-entry layer of your product then yes, Amatino would be storing your customer's financial data. My aim is to make Amatino a very low-level service, akin to an Amazon S3 for double-entry data, wherein people are comfortable building products on top of it. (A very tough goal, I know!)
In your roadmap I see "Deploy to multiple global cities based on public feedback and demand" and "Complete global deployment in all practicable global cities"
This sounds like it could be a huge waste of time compared to investing in other areas of the product. How have you determined that your customers care where your service is hosted?
Thanks for taking a look at Amatino, sciurus, I'm so excited that you got so far as the roadmap!
In "MVP" testing, I found that one of the critical problems with the service was latency. Amatino was used as the data layer for a GUI accounting application. When the service was running ~200ms+ away, the application spent too much time doing 'loading spinners' and the user experience began to suffer.
This experience led me to adopt a distributed design, that allows Amatino to sit as close as possible to end users.
Fortunately, deploying to a new region is as simple as running one script, the process is fully automated. So I don't have to worry about trading time on investing in other areas of the product.
I would not know why would anybody wish to give their accounting information to any online company, distant, unknown.
So people don't do it.
Imagine, your own accountant knows everything about you. Hyr knows your suppliers and your buyers, he has close insight in your business. And you need to be careful with him.
Best is if you can handle your accounting yourself. There is free software for that like https://www.gnucash.org and others. There is also online free software, which you can install on your intranet.
Do not install your accounting online. Internet is not for doing your private business.
And do not give your accounting data to anybody online.
Come back to basics and keep your business private!
rcdwealth, it might sound crazy, but on a personal level I agree with you! Amatino was born out of my own frustrations with existing "cloud accounting" and the implications for my data.
I am a die-hard GnuCash fanatic!
In the end, I came to the conclusion that many people want to store their data online. Whether it is their intimate photos, medical history, or bank statement. Yet some services do not meet this trust with discretion. That angers me, upsets me, and gets me fired up to write good code.
I want to give those people a way to store their financial data that is up to my paranoid privacy standards. Privacy has informed a lot of design decisions in Amatino, often to the detriment of performance or features.
I'm starting to blab on - I'd love to continue this thread though! Privacy is issue #1 for me and I would happily chat about it all day.
In other words, why does the client need to care about multiple entries in the call. I just want to record that X amount was sent from account Y to account Z. You can atomically record that as two entries in the back-end.
A single transaction should not be limited to just two nominal codes. For example, an invoice/payment might be split between Hardware, Software, Haulage and Tax/Vat and the other side would be the bank account. You also don't want to see multiple entries on your bank nominal when there was only one actual payment.
Hi kowdermeister! Thanks for taking a peek at Amatino, I'm super excited to answer your question, I'll try to keep it brief...
In my fantasy land, Amatino has replaced your 'sales_history' table completely, from an accounting perspective. As your business grows and your needs grow more complex, you would make calls to Amatino rather than developing new internal solutions.
For example, perhaps your sales_history table is implicitly denominated in Euros, but you expand into the US and now need to store U.S. Dollar amounts. In Amatino, you could instantly create a USD revenue account, and proceed to view a combined balance of all revenue accounts.
The time you would have spent dealing with manipulating double-entry data instead goes into making your product more awesome.
Obviously Amatino has a long way to go to earn that level of trust!
Thanks for taking the time to answer, but I don't get why should I opt-in to double entry bookkeeping. For someone who wants to build a side-project this is the last thing I want to think about.
Also, if you track sales in euros and dollars, then how do you track the changes in the exchange ratios?
What about rest? What happens to the data you aggregate? It just sounds like more work for me to make it available to my accountant.
Oh! I see, I apologise, I may have misinterpreted your question. Amatino would be applicable to someone who is building a project that needs double-entry bookkeeping to function. For example, they might be a fintech startup building an early invoice payment trading platform. Rather than building their own double-entry layer, they could leverage Amatino.
If double-entry accounting only exists in your project insofar as you need to account for your own business, then, as you say, Amatino would probably be an excessive solution creating unnecessary work.
Aside, on the topic of exchange rates - Amatino has built in daily exchange rates between each of 36 major currencies (You can also feed it your own, if you want more resolution / different units of account). It also automagically computes unrealised gains and losses.
Soooo many startups don't have solid accounting implemented in their money handling applications. Double entry accounting has been around for a long, long, long time, making it easy to reconcile account balances. It's just a matter of implementation.
deedubaya, I couldn't agree more. Some of the accounting implementations I have come across have made me want to barf. It is my dream that Amatino will make it easy for businesses to develop robust, performant, flexible accounting systems.
Thanks fiatjaf! The documentation definitely needs work. And worse, it only documents HTTP interactions, not the rapidly expanding client libraries! Do you have any examples of documentation you really like? I'm a big fan of Stripe's but I'm not sure if I can replicate that level of quality quickly.
Ok, actually I don't think the documentation needs to be improved a lot, I think you can get 1000% better if you add a "quick start" guide for developers. Just a small page with examples so they get the feel of it. Then they can consult the full reference if they need do to anything else.
Nice, thank you so much for those examples, fiatjaf! I actually already had a 'getting started' page (https://amatino.io/articles/getting-started) but it is nowhere near as good as those ones you've linked. Plus it obviously is not easy enough to discover! I'll review those examples and try to lift Amatino up to their standards.
PS - Strike's page is so nice! Hnnnggg. Love the little diagram.
I don’t get it. What is the point of being able to push ledger entries to this service? It isn’t really SaaS, as you’d expect to get reporting and other stuff. Plus ledger entries are pretty critical for a business and often have some regulatory requirements, which I am not sure this service could fulfil.
Thanks for taking a look planetjones! I'll try to give a worthy answer:
Amatino is trying to sit at a lower-level of the value chain than reporting, GUIs, and other layers. Amatino aims to enable others to create amazing reporting and GUIs, while charging them an extremely low price to do so.
In addition ledger entries are the simplest part of accounting. Invoices, credit notes, tax, etc. are the harder parts.
For ledger entries, create a table and SQL makes a reasonable api. Maybe some stored procedures for protecting integrity.
I humbly disagree, but very much appreciate you taking the time to critique, whatsstolat! Please allow me to present a counter argument for you to consider...
In my opinion, ledger entries are the hardest part of accounting. Invoices, etc, are all supersets of double-entry accounting, and can be reduced to collections of entries if the underlying double-entry system is sufficiently robust, generic, and and capable.
Such a system should be able to, for example, recursively sum entire account trees, while transparently translating (instantly) across heterogeneous units of account (e.g. stocks, currencies, cryptos, intangibles), and do all that on any device, on any platform, at any time, anywhere on Earth, on demand.
I know this sounds crazy - Sometimes I think I am crazy! Across the world, between companies, and even within Big4 accounting firms, there are infinite ways of constructing an 'invoice' or a 'credit note'. Everyone has their preferred way, none being right or wrong.
Amatino aims to sit below that level - Allowing developers to create their accounting system their way. No compromises.
Again, I really appreciate you looking, even if you think Amatino isn't a worthwhile project. Pondering this reply was in itself a very valuable exercise for me, so thank you for taking the time to comment!
Hi everyone - I apologise for linking directly to the Amatino blog, instead of the Amatino site itself (https://amatino.io). I deleted my initial Show HN submission, having thought I posted in the wrong place, and found I could not resubmit the same URL.
The blog is probably a good place to start anyway, as it shows real development rather than my marketing-speak!
Can you explain a bit how do you see it being used? I mean, can you describe an hypothetical application using it?
The impression I get from the site is that you're essentially a hosted database with a predefined schema, but I'm guessing there's more to it.
Good luck on the project!
I have worked with implementations of an online digital goods marketplace built by someone who was clever but had no notion of formal accounting, ledgers, etc. Their implementation worked, but was only just barely adequate and would have been more useful with a chart of accounts. Prototyping against an API like this would have been an informative exercise for them and probably saved a lot of time.
Edit: spelling
It's an accounting environment, and every system that provides goods and/or services needs to record the transactions in an accounting system. You can either use an existing accounting system such as Quickbooks, Freshbooks, Microsoft Dynamics, but then you're writing a document to those services rather than the underlying accounts forcing you to define the sales document's properties in the accounting system. In this case you should be able to keep your documents (sales invoice/credit memo) internal to your application, and the underlying account structure. In addition using Amatino should let you create accounting schedules in your application based off the ledgers. I guess you would use Amatino where you want more control over your accounting system, and I would imagine it costs less than the full-blown commercial offerings.
Right, but recording transactions is the easy part; you can even take the schema from their docs, create a few DB tables from it, and just push to a local DB.
The reason to use a real accounting system is for the extra features (mainly reports), but I don't see them in this API, so you'd still need to export your data to one of those systems. So I'm struggling to see the advantage of pushing data to their service rather than to a local DB.
More is required than a db schema; the double entry would have to be in app logic, permission model, aging, etc. Reports are nice, but in my experience I have always had to provide additional reporting on top of what is provided by an accounting system because the business had its own requirements. I see this being useful where you are trying to avoid a traditional accounting system because you willing to provide more customization.
You put it better than I can, voidmain0001! I've so often been frustrated by being unable to extend an accounting system to suit my needs.
voidmain0001 probably put it better than I can! To add to some more cents (pardon the pun): Amatino is aimed at a lower-level of the problem than reporting, GUIs, and such. Amatino provides capabilities far in excess of a self-rolled database, and allows developers to implement their wildest GUI / reporting dreams on top.
More time spent developing awesome applications, less time spent (for example) developing logic to recursively sum accounts in multiple currencies.
Thank you for taking the time to look, icebraining! I'll try to answer briefly and not get too excited!
I see Amatino used as the unsexy, unsung, unseen double-entry data layer for other apps. Perhaps those apps are fancy GUI accounting apps like Xero, perhaps they are in-house bookkeeping systems, and so on.
Amatino saves the developers of such apps from having to develop their own double-entry systems, and provides them with a rich feature-set to draw on.
Having done some work in the area, I'd say running a service is useful but many would want code / service they could license and "own". It'd probably be worthwhile if you could make a nice Kubernetes setup to run it on prem or private vpc. Lots of banks might be really interested in that! Just my two cents. :-)
Thanks for that feedback elcritch! I think you are very right. I've often wondered if I should devote time to developing a licensed solution. I will ponder it more now...
When I worked at Xero we had lots of customers using the API to do exactly this. That said, I see value in having a api independent and agnostic from the accounting backend / saas itself, but probably more relevant for larger integrations (where the cost of switching out the integration would be extremely costly). This would also be valuable for franchises or software vendors, who could build the integration once, and then have Amatino handle the integrations to each accounting system.
The primary issue becomes ensuring the integration to the accounting systems stays high value, rather than lowest common denominator. Ie: ensure reports are usable, accounting records are in a usable format (invoices, credit notes, etc rather than a bunch of journal entries), payments are applied, bank accounts can be reconciled. If that can be nailed I feel this has value.
Wow, RileyJames, thanks so much for taking a look. It's exciting to hear your thoughts as a Xero alumni. Xero is a big inspiration for me, and I love that it has made accounting easier for so many businesses.
'Independent and agnostic from the accounting backend / says' is exactly what I'm going for, and I'm really excited to hear that you see some value in the concept. I'll take your advice to heart!
We needed this to maintain accounts for our B2B products, so we came up with https://github.com/RealImage/QLedger - we deploy the ledger as an internal service (Go+Postgres+Docker) and write a 'Bank' over it for each business model that we have (two-party / multiparty). Works great so far, and is pretty solid.
Would love feedback. We haven't yet hit the scale where postgres can't sum up the transactions in time and we need to maintain caches, but we're willing to look at ideas for that.
I agree with others that I'm not sure what a SaaS API here helps with without a lot of existing integrations/bridges to other accounting systems, data lakes/BI systems, or at the very least a good general UX that provides even basic human-readable ledgers.
Also, as an API design it seems to leak abstractions that the client should maybe not worry about. If the goal is to help applications do proper double-entry accounting, then it should provide means to add transactions without knowing the gritty details specific to entries.
Aside: I worked on API side of double entry accounting program once, long ago. In college I was an intern on Microsoft Small Business Accounting (which was renamed/rebranded towards the end of while I was there to Office Accounting). It's a shame that product was cancelled, as it was good product with proper double-entry, good reports, and a great API (even despite my major attempted improvements never making it into the product before it was cancelled ;).
Hi WorldMaker, thanks so much for taking a look at Amatino. It's very humbling to know that someone with your experience has critiqued my work!
It was only six months experience directly related to this field, for what little that it is worth. :) I wish you better luck than the project I had worked on. Accounting is a tough field to compete in, because everyone thinks they can do it on the back of napkins or in Excel, up until they have to pay a CPA to tell them everything that they did wrong.
How does this work from a security perspective? If I'm an Amatino client, are you storing my customers' financial data?
If you used Amatino as the double-entry layer of your product then yes, Amatino would be storing your customer's financial data. My aim is to make Amatino a very low-level service, akin to an Amazon S3 for double-entry data, wherein people are comfortable building products on top of it. (A very tough goal, I know!)
In your roadmap I see "Deploy to multiple global cities based on public feedback and demand" and "Complete global deployment in all practicable global cities"
This sounds like it could be a huge waste of time compared to investing in other areas of the product. How have you determined that your customers care where your service is hosted?
Thanks for taking a look at Amatino, sciurus, I'm so excited that you got so far as the roadmap!
In "MVP" testing, I found that one of the critical problems with the service was latency. Amatino was used as the data layer for a GUI accounting application. When the service was running ~200ms+ away, the application spent too much time doing 'loading spinners' and the user experience began to suffer.
This experience led me to adopt a distributed design, that allows Amatino to sit as close as possible to end users.
Fortunately, deploying to a new region is as simple as running one script, the process is fully automated. So I don't have to worry about trading time on investing in other areas of the product.
I would not know why would anybody wish to give their accounting information to any online company, distant, unknown.
So people don't do it.
Imagine, your own accountant knows everything about you. Hyr knows your suppliers and your buyers, he has close insight in your business. And you need to be careful with him.
Best is if you can handle your accounting yourself. There is free software for that like https://www.gnucash.org and others. There is also online free software, which you can install on your intranet.
Do not install your accounting online. Internet is not for doing your private business.
And do not give your accounting data to anybody online.
Come back to basics and keep your business private!
rcdwealth, it might sound crazy, but on a personal level I agree with you! Amatino was born out of my own frustrations with existing "cloud accounting" and the implications for my data.
I am a die-hard GnuCash fanatic!
In the end, I came to the conclusion that many people want to store their data online. Whether it is their intimate photos, medical history, or bank statement. Yet some services do not meet this trust with discretion. That angers me, upsets me, and gets me fired up to write good code.
I want to give those people a way to store their financial data that is up to my paranoid privacy standards. Privacy has informed a lot of design decisions in Amatino, often to the detriment of performance or features.
I'm starting to blab on - I'd love to continue this thread though! Privacy is issue #1 for me and I would happily chat about it all day.
I don't think I understand this. Isn't the double-entry more of an implementation detail?
Instead of...
...you could have: In other words, why does the client need to care about multiple entries in the call. I just want to record that X amount was sent from account Y to account Z. You can atomically record that as two entries in the back-end.A single transaction should not be limited to just two nominal codes. For example, an invoice/payment might be split between Hardware, Software, Haulage and Tax/Vat and the other side would be the bank account. You also don't want to see multiple entries on your bank nominal when there was only one actual payment.
Exactly :) - Each Transaction can have (arbitrary limit) 100 entries in Amatino.
As a complete accounting noob, why should I use this?
How is this supposed to help me instead of listing the transactions from my own sales_history table of my local DB?
Do I need to create a GUI for your service listing the transactions?
Let's say I implement your service. You have all transaction data, fine, then what? :)
Hi kowdermeister! Thanks for taking a peek at Amatino, I'm super excited to answer your question, I'll try to keep it brief...
In my fantasy land, Amatino has replaced your 'sales_history' table completely, from an accounting perspective. As your business grows and your needs grow more complex, you would make calls to Amatino rather than developing new internal solutions.
For example, perhaps your sales_history table is implicitly denominated in Euros, but you expand into the US and now need to store U.S. Dollar amounts. In Amatino, you could instantly create a USD revenue account, and proceed to view a combined balance of all revenue accounts.
The time you would have spent dealing with manipulating double-entry data instead goes into making your product more awesome.
Obviously Amatino has a long way to go to earn that level of trust!
Thanks for taking the time to answer, but I don't get why should I opt-in to double entry bookkeeping. For someone who wants to build a side-project this is the last thing I want to think about.
Also, if you track sales in euros and dollars, then how do you track the changes in the exchange ratios?
What about rest? What happens to the data you aggregate? It just sounds like more work for me to make it available to my accountant.
Oh! I see, I apologise, I may have misinterpreted your question. Amatino would be applicable to someone who is building a project that needs double-entry bookkeeping to function. For example, they might be a fintech startup building an early invoice payment trading platform. Rather than building their own double-entry layer, they could leverage Amatino.
If double-entry accounting only exists in your project insofar as you need to account for your own business, then, as you say, Amatino would probably be an excessive solution creating unnecessary work.
Aside, on the topic of exchange rates - Amatino has built in daily exchange rates between each of 36 major currencies (You can also feed it your own, if you want more resolution / different units of account). It also automagically computes unrealised gains and losses.
Soooo many startups don't have solid accounting implemented in their money handling applications. Double entry accounting has been around for a long, long, long time, making it easy to reconcile account balances. It's just a matter of implementation.
deedubaya, I couldn't agree more. Some of the accounting implementations I have come across have made me want to barf. It is my dream that Amatino will make it easy for businesses to develop robust, performant, flexible accounting systems.
Very good idea, but the documentation is not very intuitive.
Thanks fiatjaf! The documentation definitely needs work. And worse, it only documents HTTP interactions, not the rapidly expanding client libraries! Do you have any examples of documentation you really like? I'm a big fan of Stripe's but I'm not sure if I can replicate that level of quality quickly.
Ok, actually I don't think the documentation needs to be improved a lot, I think you can get 1000% better if you add a "quick start" guide for developers. Just a small page with examples so they get the feel of it. Then they can consult the full reference if they need do to anything else.
For example, https://strike.acinq.co/documentation/get-started and https://developers.trello.com/docs/api-introduction
Nice, thank you so much for those examples, fiatjaf! I actually already had a 'getting started' page (https://amatino.io/articles/getting-started) but it is nowhere near as good as those ones you've linked. Plus it obviously is not easy enough to discover! I'll review those examples and try to lift Amatino up to their standards.
PS - Strike's page is so nice! Hnnnggg. Love the little diagram.
The pricing is attractive. It's low enough that I would consider prototyping against it to see if it'd work for a future project.
Ahhh! thieving_magpie your comment made me so happy! I'd be thrilled to help you tinker with Amatino, if you ever do proceed to give it a go.
I'm so glad you find the pricing attractive. I've devoted a lot of effort building the system in a cost effective way, so I can keep the price down.