Invest in learning now!

I worked for several years in a very unique setup with me being the only developer. There was me, the supplier and a guy good with CSS. This supplier had a bunch of small customers, but nothing a developer couldn't handle in a several months span. Also, I couldn't bill more than 5 hours/day in a month, but it was fine, as the rate was good.

Being a solo developer comes with some advantages like you get to choose your tools, libraries, frameworks, patterns or technologies and you get to work on all layers. As long as I delivered under the constrained budget and time, the supplier didn't really care how I did it. A big disadvantage was my only available friend when I was in trouble was StackOverflow and often wasn't much. I remember spending days and even nights to solve odd problems when it would have helped to have an experienced colleague to ask or even an extra pair of eyes to look into that missing semicolon.
I somehow successfully managed to deliver those solutions and to reduce the panic mode moments, by adopting some kind of recipe: being a heavy learner.

But who is paying?

My answer is all involved parties should pay for because everyone benefits.

If you are supplier and you just won a 5 FTE contract, don't do a team of exact 5 engineers, hire two more: one to cover the annual leave and another to buy others time to learn. You'll probably have to cut some costs to pay the extra salaries or you'll probably have to invest in it for a while.
What are your benefits? Having good technical teams will increase your confidence to bid for bigger customers. People love dopamine. You could say you've already handled it by having the espresso machine installed, but there is another way: by getting the teams to learn new things. It helps with employee retention too and it can even attract new ones.
Another good opportunity to learn is to share the knowledge. It can happen by having regular talks either at the company level or in smaller groups (team level, tech area level, role level). A different approach is to do cross-pollination between teams: get someone from a team and place him for several months in a different team and he/she will come with new ideas, techniques or technologies. But these things cost, as having tech-talks means someone has to prepare them and others to attend, so less hours in timesheet. Getting a man from a team and moving into another team means to accept the on-boarding costs until the new guy becomes productive. Thus having the extra FTE certainly helps in the long term.

But what if you are customer? Should you care? Let's face it: if I'm building my own house and hire a contractor I expect his team to have the necessary skills to raise the house. I would be very annoyed if I get an invoice with a line item saying: "research concrete factory builder  - the abstract way - 250 hours". However, lots of businesses get the technical problems solved with whatever solution was known by the development team at the time, which might not have been the best one in town. Worst, businesses have to make predictions based on the development team's expertise. If the team was not trained during the passing years then the decisions might be very expensive. So it is for the best for you to have a continuously growing development team, particularly if your relationship with the supplier is a long-lasting one. One way to do it is to have a deal between you and the supplier company, something like 3% from your contract to be dedicated to research and development. The topics could be the ones of your interest. For example, if you plan to move from Azure to AWS in the next year, it would help to have an AWS certified software engineer. You could let him study for that certification instead of having him working on some current tasks. Secure the investment by having regular tech-talks to spread the knowledge across the team.

If you are a developer, you should know no one is responsible for your career path. You might not be that lucky to have an employee to send you to conferences and neither a customer to pay for your desired certifications, but this doesn't mean you should stop learning. We have no excuses. This job requires us to learn every day. Nowadays we get outdated in two years. There are many ways to learn: learn from the code review your receive, learn from your peers, from books, podcasts, meet-ups, blogs, tech-talks, tutorials, manuals. Do tech-talks. Document your experience. Contribute to open-source projects, can be small like opening an issue or big like rolling your own. Learn a new programming language, you don't have to master it, just see how others solved the same problems. Master your main programming language. Develop your soft skills, as after a while these matter more than your tech skills. Find your return of CV in everything you do every day.

I experienced with this model in the past when I was working like 4 hours a day, but billed 5 and also spent about one or two hours to learn and try things. Everyone paid. It worked as I grew and survived quite a few technology changes. It worked for my employer too as I was doing more things and within better quality metrics in fewer hours. It worked for his customers too as many of the technical solutions meant switching businesses ' focus from technical problems on what they do best: find business opportunities.

Are you willing to pay?