A Plea for more Mikado

Mike's Notes

Here is an article that I discovered in the latest Amazing CTO newsletter.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Amazing CTO
  • Home > Handbook > 

Last Updated

10/03/2025

A Plea for more Mikado

By:  Damien Mathieu
dmathieu.comMonday, August 21, 2023

One of the books that impacted the most my career is probably The Mikado Method. I read it almost 10 years ago, and I don’t practice it explicitly. But I think of the method almost every day, and it has been impacting how I work ever since.

And yet, it has remained something quite obscure. Whenever folks suggest must-read computer science books, it’s never there. So let’s try to explain it a bit more, and how it can be used every day in the life of a programmer.

What is the Mikado Method?

If you ever worked on a large refactoring project, library switch or upgrade, you may have ended up working in a branch for weeks (or months). You need to regularly rebase against the main branch (or have everybody working on the same branch), and may end up spending more time fixing conflicts than actually working on the change.

But somehow you move forward, and one day you are ready to ship that huge change. The biggest bet still lays ahead of you though: will there be performance changes? Did we miss something? Were there unknown bugs? In my experience, every big bang change always ends up in at least one cycle of reverting and going back to the PR, and a non-trivial number of them were not shipped at all.

The Mikado Method is a framework to make that kind of refactoring manageable.

The idea is to split things into atomic changes. Each of these changes will be shipped right away, on its own.

Let’s say you’re working on a Ruby on Rails application which hasn’t been upgraded in several years. So you need to go from Rails 4 to Rails 7 (wow!).

Let’s do it with some mikado!

The first step will be to locally upgrade the rails dependency in your Gemfile to the final version you want to run on. On a paper, draw a rectangle (or a circle, anything) and write down a couple words about the task you’ve just down, such as upgrade rails in Gemfile.

Now, run your unit test suite. Obviously, there will be lots of failures.

Go through each failure, and for each of them write a new rectangle on the paper, with a (very) short description of what you would have to do to fix that issue. If the cause is unknown at that point, you can also write down the failure itself, to be investigated. Link each rectangle to the parent one, as can be seen in the example image below.


Then, revert your changes. Delete everything! And I really mean revert, not move to a new branch or squash. If you feel this change took you too long to just be deleted, it means it wasn’t atomic enough and you need to split it.

Now, pick one of the failures you wrote down, any of them and try to fix it in the current codebase, without the original upgrade. Doing so may require some refactoring or more changes. In that case, don’t do them. Write them on your paper, delete everything and start implementing them. Similarly, if after fixing the problem, there are still failures, write them down, link them to the issue you were just trying to fix and delete everything.

And iterate from there against every failure, refactoring or change you need. If you discover a new issue, write it down and delete everything.

At some point, you will get a fix which actually works and for which all your tests pass. Ship that change!

And move on to the next failure.

Over time, you will get more and more actual fixes, and less and less reverts. Until all there is left to do is to make the change where you actually change the content of your Gemfile to upgrade the dependency version.

At that point, your application supports both versions, making that change very small and trivial to ship. Do it of course!

Obviously, the Mikado Method cannot work if you don’t have a good and highly reliable automated test suite.

Wow dude, this is too much

It absolutely is. And I haven’t heard of anyone following this process to the letter.

But processes aren’t meant to be followed to the letter. They are meant to provide a frame. Once that process is fully understood, getting out of it can be beneficial, to adapt it to your own needs, while retaining the core ideas and goals of that process.

In the case of the Mikado method, I think the biggest takeaways are to ship atomic changes, and not be afraid to drop things if they derail.

Atomic Everything

There’s nothing worst (well …) than seeing a Pull Request describing something, but where other unrelated (yet relevant) changes crept in.

Whenever I am working on something, and I notice something else in the same bit of the codebase which should be changed or refactored, I take a note of it, and come back to it once my original change is ready for review. I see this as a lighter way of doing Mikado. And yet, everything in a PR is related to the same thing, making its review much easier.

One way to cheat about this would be to name the PR “do this and that”. Well, don’t! If your PR includes an and, there should be two of them (the same goes for issues).

The gist of it is: split everything you do into the smallest bit possible, and ship all those bits independently.

A failure of an example

Here is an example why thinking about everything atomically is safer. At $PREVIOUS_EMPLOYER, we wanted to migrate from Opentracing to OpenTelemetry.

Both libraries are quite similar, but we had some heavy internal things that couldn’t work exactly the same between both of them, so we wanted to ensure there were no performance regression with the change. Hence we decided to do a big bang PR to be able to run performance tests.

I worked for over a month just making the appropriate changes, the PR was huge, and then I worked for another month just on the benchmarks. Until we were ready to ship the change.

Due to errors unseen before and uncaught by unit tests, Wwe shipped and reverted 3 times before deciding to drop a quarter of work and restart from scratch with small PRs we could ship daily.

To be fair, this quarter wasn’t entirely lost, since it brought us benchmarks we wouldn’t have had this soon were it not for a big bang change. But the frustration was there anyway. And I am sure that if we had decided to keep on trying to ship that big bang PR, we would have ended up reverting more than 10 times.

Delete your WIP code

I am sometimes stuck into a fix that seems daunting. The more I fix things, the more there are to fix, and it seems like I’m never going to get over it. Well, this is exactly the kind of moment where deleting everything and starting from scratch again is highly beneficial.

Once again, I do mean delete. Not squash or branch off of. There is a real psychological value in deleting a change where you’re stuck to start fresh.

However, when you do that, you should start working on the new fix right away. Don’t wait for a couple days. You don’t have the code available, but your mind is still there. That’s what’s going to allow you to go back there much more quicker and better than you did the first time.

Said like this, it may seem the need to delete WIP code like this is pretty exceptional. I’ve personally grown to make it quite standard. Whenever I spend more than 15-20 minutes stuck on something, I’m usually going to delete it and start fresh.

This can only work because I am a bit extreme about making everything atomic. So I also very often have something that works and I can commit. When that happens, I only delete whatever’s not been committed yet. Not all the unpushed commits I made earlier. Every of those atomic commits must have a green local test run of course.

Conclusion

Mikado is much like the agile method. It’s something everybody should apply to some degree, but not follow to the letter. But working with it in mind provides a very good base to ship code (whether it be a small bugfix, or a very large refactoring) in a safe and reliable way.

It’s probably not something everybody should do as described in the book (though if you do try it for a large enough project, I’d be happy to hear about it). But I am convinced that having some experience of it will make anyone a better developer!

It helps to be organised but not too organised

Mike's Notes

This is how I keep notes.

Resources

References


Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

18/04/2025

It helps to be organised but not too organised

By: Mike Peters
On a Sandy Beach: 09/03/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Yesterday and today are filing days.

I draw my ideas on paper and then make stuff from them. As a result, I generate at least one or two thousand pages of handwritten notes a year.

  • I have also used pocket notebooks with sequential daily notes, but I prefer A4 paper because it can be sorted later by subject or idea.
  • I carry a leather A4 organiser everywhere, constantly drawing and making bullet points while drinking coffee.
  • There is a direct correlation between morning coffee and paper generated.
  • I also photocopy helpful illustrations from books.
  • I use colour highlighters all over the place. Using colour helps me mentally structure stuff.
  • The A4 white pages are stacked neatly until I can't find anything, and then filing begins by project, sub-project, etc.
  • I use a hierarchical physical file structure that maps to my digital filing structure of nested folders.
  • I use 3-hole ring binders with the same folder names, with card dividers containing colour paper cover sheets to provide three division levels.
  • I then use the binders as a reference source, often reworking the notes into a few consolidated pages and throwing out the rest.
  • Projects in production go on a kanban board.
  • I have 30 years of organised notes and 40 years of shelved pocket notebooks.

I use the same system for film, art, and software projects.

Today, I set aside 2 hours weekly to organise my notes.

Embedding Wolfram Notebooks

Mike's Notes

My working notes on building the first plug-in.

Resources

References


Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

11/05/2025

Embedding Wolfram Notebooks

By: Mike Peters
On a Sandy Beach: 04/03/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

I want to visually explain to Ajabbi users the maths that Pipi uses. I am not a mathematician, but I have learned to use maths visually in experiments and for analysing data.

Pipi

Pipi makes use of these kinds of maths:

  • Fuzzy Logic
  • Markov
  • Monte Carlo
  • Statistics
  • Algorithms
  • Etc

Ajabbi SaaS

The applications being built also need to use math directly, and users may need access to mathematical tools. The Pipi Content Management System Engine (CMS) generates the UI and content on every web page, so this means using forms rather than direct coding.

Wolfram

Last year, I took some free online training provided by Wolfram on creating and editing Notebooks. Afterwards, one of their people contacted me, leading to an open discussion about how to embed Wolfram Notebooks and maths training on the Ajabbi website.

One of their partnership people contacted me. They said that WordPress had also provided embedding. So, the first port of call is to see how WordPress does it.

Since then, Wolfram has kindly given me access to Wolfram One for three months so that I can experiment, test, and post some examples.

To do

  • Make the first plug-in to embed Wolfram Notebooks onto the ajabbi.com web pages using a simple web form.
  • Extend the plug-in to be generic and work with other 3rd-party websites.
  • Configure an embedded notebook to analyse live data at Ajabbi (I don't know how yet).
  • Embed free relevant maths instruction beside the notebooks.

WordPress

WordPress offers a plug-in for embedding content from third-party websites. The plug-in appears as a simple web form.

Embedding

Embedding makes use of the HTML tag iFrame.

Code

<iframe src="demo_iframe.htm" height="200" width="300" title="Iframe Example"></iframe>

Properties

Attribute Value Description
allow   Specifies a feature policy for the <iframe>
allowfullscreen TRUE Set to true if the <iframe> can activate fullscreen mode by calling the requestFullscreen() method
FALSE
allowpaymentrequest TRUE Set to true if a cross-origin <iframe> should be allowed to invoke the Payment Request API
FALSE
height pixels Specifies the height of an <iframe>. Default height is 150 pixels
loading eager Specifies whether a browser should load an iframe immediately or to defer loading of iframes until some conditions are met
lazy
name text Specifies the name of an <iframe>
referrerpolicy no-referrer Specifies which referrer information to send when fetching the iframe
no-referrer-when-downgrade
origin
origin-when-cross-origin
same-origin
strict-origin-when-cross-origin
unsafe-url
sandbox allow-forms Enables an extra set of restrictions for the content in an <iframe>
allow-pointer-lock
allow-popups
allow-same-origin
allow-scripts
allow-top-navigation
src URL Specifies the address of the document to embed in the <iframe>
srcdoc HTML_code Specifies the HTML content of the page to show in the <iframe>
width pixels Specifies the width of an <iframe>. Default width is 300 pixels

Foundation examples

Mike's Notes

I am considering establishing a foundation to support Ajabbi and its users. Here are some examples of other "public-good" foundations.

Resources

References


Repository

  • Home > Handbook > Ajabbi > Foundation

Last Updated

05/06/2025

Foundation examples

By: Mike Peters
On a Sandy Beach: 07/03/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Here are some examples of Foundation descriptions from their websites.

  • Raspberry Pi Foundation
  • Linux Foundation
  • Apache Foundation
  • Wikimedia Foundation

Raspberry Pi Foundation

The Raspberry Pi Foundation is a UK-based charity that aims to enable young people to realise their full potential through the power of computing and digital technologies.

Linux Foundation

Innovation comes from everywhere. We help companies and developers identify and contribute to the projects that matter. Working together, the open source community is addressing the challenges of industry and technology for the benefit of society. Code is power. Community is a strength. We are one.

Apache Foundation

The Apache Software Foundation (ASF) exists to provide software for the public good. We believe in the power of community over code, known as The Apache Way. Thousands of people worldwide contribute to ASF open source projects every day.

Wikimedia Foundation

The Wikimedia Foundation is the nonprofit that hosts Wikipedia and our other free knowledge projects. We want to make it easier for everyone to share what they know. To do this, we keep Wikipedia and Wikimedia sites fast, reliable, and available to all. We protect the values and policies that allow free knowledge to thrive. We build new features and tools to make it easy to read, edit, and share from the Wikimedia sites. Above all, we support the communities of volunteers around the world who edit, improve, and add knowledge across Wikimedia projects.

The Rot Economy

Mike's Notes

Ed Zitron's blog post in 2023 on Silicon Valley behaviour provides a fascinating insight. I copied it from his blog.

Resources

References


Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

11/05/2025

The Rot Economy

By: Ed Zitron
Where's your Ed At?: Feb 9, 2023

At the center of everything I’ve written for the last few months (if not the last few years), sits a cancerous problem with the fabric of how capital is deployed in modern business. Public and private investors, along with the markets themselves, have become entirely decoupled from the concept of what “good” business truly is, focusing on one metric — one truly noxious metric — over all else: growth.

“Growth” in this case is not necessarily about being “bigger” or “better,” it is simply “more.” It means that the company is generating more revenue, higher valuations, gaining more market share, and then finding more ways to generate these things. Businesses are expected to be - and rewarded for being - eternal burning engines of capital that create more and more shareholder value while, hopefully, providing a service to a customer in the process. In the public markets, that means that companies like Google, Meta, and Microsoft were rewarded for having unfocused, capital-intensive businesses that required mass layoffs when times got tough, because the market loved the idea that they’d found a way to save money. They weren’t punished for their poor planning, their stagnating products, their mismanagement of human capital, or their general lack of any real innovation because the numbers kept going up.

When I wrote in October that Mark Zuckerberg was going to kill his company, the street responded in kind, savaging Meta’s stock for burning cash building a metaverse that was never going to exist. Yet once Zuckerberg fired 11,000 people and claimed that 2023 would be the “year of efficiency,” the market responded with double-digit increases in the price of Meta’s shares, despite the fact that Facebook’s active user growth declined and they lost $13.7 billion on the same metaverse department that caused the stock to drop the last time.

The markets seemed to ignore the $410 million fine that Meta received for GDPR violations, along with the fact that European users will now have to deliberately opt-in to sharing their data - which is bad, considering only about 25% of iOS users choose to opt-in to app tracking, and their business model is intrinsically linked to the repurposing of customer data into ad targeting telemetry.

Let’s be abundantly clear: Meta’s core advertising models depend heavily on things that likely become impossible to do legally (or even technically, given Apple’s App Tracking Transparency, Alphabet’s retirement of the third-party tracking cookie, and the Chromium Project’s planned blocking of non-cookie fingerprinting technologies) in the next decade. Their other products simply do not make that much money. Their CEO’s big idea to make more money has lost them billions of dollars, and likely won’t make them any for quite some time. Yet Meta remains beloved, because the numbers are going up.

Killing Innovation

Google has a similar yet slightly different story, where their core product - search - has gone from a place where you find information to an increasingly-manipulated labyrinth of SEO-optimized garbage shipped straight from the content factories. As Charlie Warzel put it last year: “Google Search, what many consider an indispensable tool of modern life, is dead or dying.”  Users have to effectively find cheat codes - adding things like “[whatever you’re searching]+Reddit” to get reliable answers. Despite its decades-long efforts to improve the quality of organic results, Google remains easily-gamed by anyone who knows how to craft an algorithm-friendly headline.

Without finding a way to negotiate with Google Search, you’re offered a fragmented buffet of content provided by Google’s algorithm, either based on how much they’ve been paid to prioritize said content or by how companies have engineered content to rank higher on search. Google no longer provides the “best” result or answer to your query - it provides the answer that it believes is most beneficial or profitable to Google. Google Search provides a “free” service, but the cost is a source of information corrupted by a profit-seeking entity looking to manipulate you into giving money to the profit-seeking entities that pay them.

The net result is a product that completely sucks. “Googling” something is now an exercise in pain, regularly leading you to generic Search Engine Optimized content that doesn’t actually answer your question. Google’s push to hyper-optimization has also led it to serve results based on what it *thinks* people mean, rather than what they actually said. It’s frustrating, upsetting and annoying. A problem that likely hits hundreds of millions of people a day, yet Google doesn’t have to change a thing, because the street likes that they have found more innovative ways to get blood from a stone. These moves are unquestionably hurting Google, to the point that Microsoft’s Bing (paired with OpenAI’s ChatGPT), has gained major headlines for providing the service that everybody wished Google would.

That’s because Google has, like every major tech company, focused entirely on what will make revenues increase, even if the cost of doing so is destroying its entire legacy. Google has announced their own “Bard AI” to compete with Bing’s ChatGPT integration, and I’ll be honest - I feel a little crazy that nobody is saying the truth, which is that Google broke the product that made them famous and is now productizing fixing their own problem as innovation.

That’s because the markets do not prioritize innovation, or sustainable growth, or stable, profitable enterprises. As a result, companies regularly do not function with the intent of making “good” businesses - they want businesses that semiotically align with what investors - private and public - believe to be “good.”

Despite its ubiquity, companies like Uber should not exist. Uber has not made a profit from its businesses. They had a net loss of 1.21 billion last quarter, yet the street fell over itself to praise the company because “gross bookings grew 19% year-over-year” for their unprofitable businesses that largely hinge upon the government failing to impose sensible labor laws, a con that will eventually come to an end, and indeed, has ended in some territories like the UK, where Uber drivers are now recognized as employees, and are therefore entitled to pensions, paid vacation time, and a minimum wage. London, I note, is one of Uber’s most important markets.

Yet as of writing, Uber’s stock is up 5%.

The media itself somewhat fuels this economy of growth-mongering. CNBC reports earnings like many other media entities, but their reports on, say, Uber fail to acknowledge the fact that Uber has spent nearly 15 years burning money. It has never turned a profit. Even with its push into freight and food delivery, it  may never turn a profit, no matter how much it contorts its financials to pretend otherwise. Yet acknowledging the truth is that much worse because Uber will not be killed, because people keep buying the stock, because it is a “valuable company” in the eyes of markets that have fucking cataracts.

This is why we see such vast oscillations of hiring and firing - because these companies are never, ever punished for failing to operate their businesses in a sustainable way, or even with a view for the future, particularly when it comes to macroeconomic trends that literally everyone else saw coming.

Their business models were predicated on an endless supply of cheap money, even though the Fed steadily ratcheted interest rates in the years leading up to the Covid pandemic, only slashing them to mitigate the pain of Covid and (to a lesser extent) the US-China trade war.. The specter of inflation reared its ugly head as early as 2020, first driven by the lockdown-induced chaos on supply chains, and then exacerbated further by the war in Ukraine, the collateral damage of China’s Zero Covid policy, and a chronic labor shortage in most industrialized countries.

The markets do not react when they are mass-hiring people to capture consumer demand. They do not react to the fact that Microsoft, for example, seems to be laying off people almost every year. In 2020, CEO Satya Nadella called for a “referendum on capitalism,” telling businesses to start to grade themselves on the “wider economic benefits they bring to society, rather than profits.” To be clear, this was four months after Microsoft laid off 1000 people, one year before they hired 23,000 people, and a few months after which they laid off 10,000 people to “deliver results on an ongoing basis, while investing in [their] long-term opportunity.”

Everything Ventured, Nothing Gained

Before these companies reach the public markets, they are fueled by an even more violently reckless form of funding - venture capital. Venture capitalists are regularly incentivized to create businesses that look valuable but aren’t necessarily of value. When I wrote about the Liches of Silicon Valley last year, I remarked upon how many valley companies experience volatile, erosive cycles of growth with the goal of being acquired or going public, burning as much venture capital as it takes to find an outcome:

They repeat a very specific cycle - company is the next big thing, company is now worth over a billion dollars, company is experiencing “unheard of growth” (with no question as to whether they are sustainable or profitable), company is now challenging ‘the big dogs’ of industry, a little M&A, an absolutely insane valuation, and then a sudden realization that actually, perhaps this wasn’t a good business at all? I am hammering on TechCrunch links here because I am being lazy - they are far from the only outlet to assume that a company like Brex would not simply run itself into the ground through virtue of existing - but the path is always the same - growth, growth, growth, legitimization, growth, growth, acquisition, and then an eventual reckoning with real life.

Venture pumps millions or billions of dollars into ideas that might sell a product or a service, but ultimately resemble things that can be sold to other companies or put on the public market for a profit higher than what was paid on a per-share basis. I once suggested that Silicon Valley conflated “making great ideas work” with “making ideas I like work,” but on consideration, many of these companies aren’t even things venture capitalists like - they are things that resemble things that they can sell. Do I genuinely believe that everyone who invested into the Web3 grift was a strident believer in the brave new decentralized economy? Hell no. They just went where the winds blew — or where they seemed to be blowing.

Andreessen Horowitz was the lead participant in arguably the biggest con in venture capital, pumping billions into Web3 companies that didn’t have any real product, but stapled together enough buzzwords and websites to resemble actual entities. A16Z found a way to vastly accelerate the idea-to-business-to-profit cycle of venture. Despite claiming it was “Time To Build” in 2020, Andreessen Horowitz realized that there wasn’t ever really much of a need to build at all - you could create things that semiotically aligned with what “valuable” looked like and profit off of that. While the public markets may (at least, before the rise of the SPAC) have required some sort of business - even if said business wasn’t graded on being a “good” one - the cryptocurrency markets allowed the vaguest of ideas to get even vaguer valuations.

This same insipid thought process applies to the rest of their portfolio too. Adam Neumann, a guy who is most famous for running WeWork into the ground, got a second at-bat with his new startup “Flow,” a company that Neumann is still not able to fully describe, but that may involve you renting to own an apartment that Flow owns somewhere at some point. Just like Silicon Valley can’t help itself from reinventing the bus, Neuman is seemingly attempting to reinvent the rental market — a diseased, exploitative industry in its own right — in his own image. He’s replacing one cancer with another, only even more aggressive and metastatic.

Neumann was, is, and will always be full of shit. Appropriately, in a video A16Z released yesterday, Neumann used the following analogy to describe Flow:

The founder turned to a toilet metaphor to explain one aspect of his idea of ownership. “If you’re in an apartment building, and you’re a renter, and your toilet gets clogged, you call the super,” he said. In contrast, “if you’re in your own apartment, and you bought it and you own it and your toilet gets clogged, you take the plunger.” For Neumann, fixing up your own apartment means shifting from “being transactional to actually being part of a community” and “feeling like you own something.”

In a functioning society, Adam Neumann would not be given a single dollar. This quote proves that he has never unclogged a toilet, because in the event that you could unclog your toilet in an apartment you rented, you’d probably do it. If the clog was so severe it required the super, you would probably still call a plumber if you owned the place, because your nasty business has created a problem you cannot solve.

What I am suggesting is that Adam Neumann doesn’t know anything about home ownership, or unclogging toilets, or toilets, or the regular experience of being a human. Yet he is given unfathomable amounts of capital to address problems related to these things, because he has the resemblance of the kind of messianic white guy that is able to take a product and sell it, even if he is quite literally the guy who failed to do this before.

Neumann turned a (nominally) $47bn company into a $2.9bn company. In a sane and just world, he wouldn’t see a dollar of funding for the rest of his life.

There are tons of other examples of colossally stupid assholes and stupid ideas getting money. As I wrote about on Monday, the largest investment rounds of the last few years have gone to companies that got obscene valuations based on nothing other than a vague sense of them “looking like a winner.” There is no reason a weight loss app should need $540 million to operate - that is not a sustainable enterprise considering the entire weight loss industry is worth about $3.8 billion. Clubhouse was never worth the billions of dollars pumped into it, considering the entire radio industry only makes about $12 billion a year combined. While capital is required to get a company off the ground, the only way to justify these massive surges of capital is that venture capitalists are putting companies on life support in the hopes that they can flog them for a profit.

And this corrosive capital system gets continually rewarded. Companies like Uber are taken public, making massive windfalls for venture capitalists without ever having to run a profitable business. Venture capitalists crammed $41 billion into crypto in the space of 18 months, despite there being no real use cases for crypto. Metaverse companies raised $120 billion in 2022 for a concept that has yet to really exist, and perhaps never will. Yet these concepts get vast amounts of money because venture capitalists are incentivized to pump cash into “good companies to invest in” over “good companies.”

As my friend Kasey put it in a recent conversation, growth is a fire. If you build a nice, sustainable fire, it’ll keep you warm, cook food and sustain life. And if the only thing you care about is how big your fire is, then it’ll set fire to everything around it, and the more you throw into it, the more it’ll burn. Eventually, you’ll have nothing left, but if you desperately desire that fire, you will constantly have to find new things to burn at any cost.

And we, societally, have turned our markets and businesses - private and public - over to arsonists. We have created conditions where we celebrate people for making “big” companies but not “good” companies.

Venture capital and the public markets don’t actually reward or respect “good” businesses or “good” CEOs - they reward people that can steer the kind of growth that raises the value of an asset. Elon Musk’s success with Tesla didn’t come from the inarguable point that he ended the monopoly of the internal combustion engine - it came from his canny manipulation of the symbolic value of a stock through lies and half-truths, meaning that there was always a perpetual reason that Tesla was a “growth” company and a “good stock to buy.” Sundar Pichai isn’t paid $280 million a year because he’s a “good CEO.”  After all, Google has all but destroyed its search product. He’s paid because he finds ways to increase the overall growth of the company (even while their cloud division still loses money), and thus the stock goes up.

The consequences are that these companies will continue to invest in things that grow the overall revenue of the company over all else. They will mass-hire and mass-fire, because there are no consequences when the markets don’t really care as long as the company itself stays valuable. Venture capitalists certainly don’t mind - after all, it’s “less burn” to “get you through” tough climates that were arguably created by the poor hiring decisions of a company that was never incentivized to hire sustainably or operate profitably.

Until we see a seismic shift in how major investors treat the companies they invest in, this cycle will continue. I guarantee that we will see each and every one of the companies doing mass layoffs do mass-hirings in the next few years, and then do another mass layoff not long after, because they are simply treating human capital as assets to be manipulated to increase the value of a stock. They are not structured to evaluate whether the business is “sustainable,” because their only interest is seeing their current profits grow by multiples that please Wall Street.

“Good companies” should not have to repeatedly lay people off. They should not be mass-hiring for fear that the demand they are capturing is temporary, and those new employees will soon find themselves at the receiving end of a pink slip.

The lens through which we evaluate businesses is cracked, and until we fix it, we will continue to experience these punishing cycles of binging and purging on human capital.

This is the problem at the center of almost everything I’ve written. Why are bosses mad they can’t bring people back to the office? Because their alignment of business success isn’t really tied to profit or “success,” but rather the sense that they are “big” and “successful,” which requires a bustling workplace and “ideas.”

Why did billions of dollars get pumped into crypto’s countless non-companies? Because “success” as defined by capital has been reframed to mean “number go up.” As a notion, it is divorced from any long-term thinking, fiscal probity, or even what you and I would call “morality.”

Why did these companies never seem to get blamed for hiring and then quickly firing tens of thousands of people? Because at the heart of the business media and the markets, workers were necessary casualties of the eternal struggle for growth. Layoffs are inevitably reported as a large number (“10,000 employees at Microsoft”), which makes it all too easy to remove the human element. When confronted with numbers of this scale, it’s easy to ignore the individual human agony that comes with losing a job. The uncertainty and shame that follows a firing.

The truth is that nothing lasts forever. Companies can (and should) die — or, at the very least, understand that there is an inevitable limit to growth, and eventually they must reconcile with being a stable, albeit plateaued, business.

A product may be profitable for a while, but there is a line at which profitability comes at the cost of functionality, and your company may simply not be able to grow more. A business that cannot generate profit is not a good business, and a business that can never generate a profit deserves to die.

And the net result of all of this is that it kills innovation. If capital is not invested in providing a good service via a profitable business, it will never sustain things that are societally useful. Companies are not incentivized to provide better services or improve lives outside of ways in which they can drain more blood from consumers. And the street doesn’t care either - just look at Facebook and Instagram, two products that have grown endlessly profitable and utterly useless in the process.

If capital wishes to call labor entitled, capital must acknowledge that it is the most entitled creature in society, craving eternal growth at the cost of the true value of any given service or entity.

Against the odds: 12 women who beat bias to succeed in science

Mike's Notes

Recently, I read the biography of Katlin Karikó, an incredible woman scientist from Hungary who devoted her entire working life to finding a way to get cells to heal themselves using their cellular machinery (mRNA, etc.).

"Katalin Karikó has had an unlikely journey. The daughter of a butcher in postwar communist Hungary, Karikó grew up in an adobe home that lacked running water, and her family grew their own vegetables. She saw the wonders of nature all around her and was determined to become a scientist. That determination eventually brought her to the United States, where she arrived as a postdoctoral fellow in 1985 with $1,200 sewn into her toddler’s teddy bear and a dream to remake medicine. 

Karikó worked in obscurity, battled cockroaches in a windowless lab, and faced outright derision and even deportation threats from her bosses and colleagues. She balked as prestigious research institutions increasingly conflated science and money. Despite setbacks, she never wavered in her belief that an ephemeral and underappreciated molecule called messenger RNA could change the world. Karikó believed that someday mRNA would transform ordinary cells into tiny factories capable of producing their own medicines on demand. She sacrificed nearly everything for this dream, but the obstacles she faced only motivated her, and eventually she succeeded.

Karikó’s three-decade-long investigation into mRNA would lead to a staggering achievement: vaccines that protected millions of people from the most dire consequences of COVID-19. These vaccines are just the beginning of mRNA’s potential. Today, the medical community eagerly awaits more mRNA vaccines—for the flu, HIV, and other emerging infectious diseases.

Breaking Through isn’t just the story of an extraordinary woman. It’s an indictment of closed-minded thinking and a testament to one woman’s commitment to laboring intensely in obscurity—knowing she might never be recognized in a culture that is driven by prestige, power, and privilege—because she believed her work would save lives."

Apart from her heroism in the face of overwhelming odds, what struck me was her description of the lack of decent childcare in the US, compared to Hungry,  as a barrier for women in the workforce.

When I get Ajabbi up and humming, one of the first things I will organise is to provide free, unlimited, quality childcare so women with kids can work. All work at Ajabbi needs to be family-friendly.

I am looking for the Katlin's of this world.

The article below is reprinted from Nature and is a book review.

Katlin Karikó

Resources

Repository

  • Home > Ajabbi Handbook > Ajabbi Research > Staff > Childcare

Last Updated

  • 05/03/2025

Against the odds: 12 women who beat bias to succeed in science

By: Georgina Ferry
Nature: 03 March 2025

A book deftly highlights how women have been considered unsuitable as researchers for reasons other than their ability and commitment.

Against the Odds: Women Pioneers of Science John Gribbin and Mary Gribbin Icon Books (2025)

What is it with toilets? In domestic households, men and women use the same ones without a fuss, but at some point in history it became etiquette for toilets in workplaces to be segregated. And in supposedly male environments, it meant that there simply weren’t any for women. It then became absurdly easy to use the lack of appropriate toilets as an excuse to deny women a role in those environments or, if they did take a job there, to make their lives difficult.

Toilets come up in several of the 12 stories selected for John and Mary Gribbin’s gallery of female pioneers in science, Against the Odds. In the opening years of the twentieth century, physicist Lise Meitner, banished to a basement because she wasn’t allowed to work in the chemistry laboratories of what was then the Royal Friedrich Wilhelm University of Berlin, had to use the toilets in a neighbouring restaurant. During the 1950s, computer pioneer Lucy Slater, while developing the operating system for an early computer at the University of Cambridge, UK, smashed the sanitary equivalent of a glass ceiling by simply using the men’s toilet (singing loudly to signal her presence). And in 1964, Vera Rubin became the first female astronomer who was officially allowed to use the big telescopes at the Mount Wilson and Palomar observatories in California, overturning a ban that had been partly, but explicitly, based on the lack of a women’s toilet.

Science trailblazers

Compared with unequal pay for the same work, the reality of men with fewer qualifications being promoted ahead of them and the frank refusal to recognize that a married woman with children might be capable of a career, the toilet issue was probably a trivial annoyance to these women. But it symbolizes how, for centuries, women have been considered unsuitable as scientists for reasons that have nothing to do with their ability or commitment.

The Gribbins’ aim is to “highlight the achievements of women who overcame the odds and achieved scientific success ... as society changed over about 150 years”. They don’t justify their selection, other than to note that the women featured (ordered by year of birth) collectively cover the period. But it is startling that physicist Chien-Shiung Wu is the only scientist who is not white or born in a Western country (and she spent most of her career in the United States). The ‘hidden figures’ — African American women who calculated trajectories for early NASA space missions — remain hidden. Many girls won’t find a role model who looks like them in the book.

With that caveat, the Gribbins tell the stories with an adroit mix of anecdote and exposition. There is a bias towards physical sciences, perhaps reflecting John Gribbin’s background in astrophysics. Some of those featured (such as crystallographer Rosalind Franklin) are close to being household names, others (geophysicists Eunice Newton Foote and Inge Lehmann) are much less familiar. Three of the women (chemists Irène Joliot-Curie and Dorothy Crowfoot Hodgkin and geneticist Barbara McClintock) won Nobel prizes; two (Meitner and Wu) should have done.

Some of the women were less celebrated during their lifetimes. It took 100 years for historians to uncover the work done by Foote, as a wealthy ‘lady amateur’ working in her home lab in New York state. She demonstrated that water vapour and carbon dioxide absorbed energy from sunlight and so could increase global temperatures. Her 1856 paper included the statement that if “the air had mixed with it a larger proportion [of CO2] than at present, an increased temperature ... would have necessarily resulted”. Three years later, John Tyndall, unaware of Foote’s work, performed the experiments that are generally credited with establishing the nature of the ‘greenhouse effect’.

Equal partners?

Foote was a suffragist and abolitionist who married an equally enlightened husband, working together at the lab bench. Men have an important role in these women’s accounts, as enablers or obstructors — sometimes both. Meitner’s work on radiation involved a decades-long collaboration with chemist Otto Hahn. The relationship seems to have been fruitful and harmonious, and Meitner gradually overcame institutional prejudice to achieve professional recognition. But the advent of Nazism led her to flee to Stockholm, where she came up with the idea of nuclear fission in conversation with her nephew Otto Frisch. After correspondence with Meitner, Hahn confirmed its existence experimentally and he alone was awarded the chemistry Nobel prize in 1944. Far from insisting — as Pierre Curie had done for his wife and co-worker Marie — that the prize should be shared with Meitner, he allowed a narrative to develop that she had been his assistant, when the opposite was nearer the truth.

As a biographer myself (disclosure — the Gribbins’ chapter on Crowfoot Hodgkin draws on my book, with attribution), I can’t stress too strongly the importance of the formative years in determining whether women pursue scientific careers. German mathematician Emmy Noether was typical of this group in having highly academic parents — her father was also a distinguished mathematician — who paid for her to have private tuition in the subject at the beginning of the twentieth century, when German universities were not open to women. A rearguard attempt to stop her from gaining a university position made the extraordinary claim that “a woman ‘is unsuitable for regular instruction of our students because of the phenomena connected with the female organism’”. Growing up in a family that says ‘yes you can’ in a society that is still saying ‘no you can’t’ makes all the difference in imparting the sense of agency that fuels a determination to continue against the odds.

Motherhood might be seen as one of the biggest obstacles, once institutional sexism has been excluded, although the two cannot be disentangled completely. In 1923, Leslie Comrie wrote a letter in support of fellow astronomer Cecilia Payne-Gaposchkin, who was a student at the University of Cambridge, UK, at the time. Payne-Gaposchkin wanted to work at the Harvard College Observatory in Cambridge, Massachusetts, and in his letter, Comrie assured the observatory’s director that “she would not want to run away after a few years training to get married”. She didn’t run away but, some ten years later, did marry émigré Russian astronomer Sergei Gaposchkin, and they had three children with no noticeable effect on her prodigious research output on stellar evolution and the composition of stars. Payne-Gaposchkin and Crowfoot Hodgkin share the distinction of having given prestigious public lectures while pregnant (and in Crowfoot Hodgkin’s case, under her maiden name of Crowfoot).

Half of those featured in the book became mothers; others, such as Lehmann and McClintock, made a nun-like commitment to science above all else. Yet they all had a passion for discovering more about the natural world, and a joy in doing so, that enabled them to overcome all obstacles. Historians might frown on collections, such as Against the Odds, that put a spotlight on individuals. But they serve to remind young women who find it hard to have a scientific career that this has often been the case, and that hanging on to that quest for joy is worth it in the end.

As noted in Against the Odds, Nobel-prizewinning physicist Richard Feynman’s sister Joan decided to become an astrophysicist after he gave her an astronomy textbook containing a graph credited to Payne-Gaposchkin. It gave her the ammunition she needed to defy her mother and insist that girls could do physics. The need for such ammunition is less today than it was in 1941, but it hasn’t disappeared.

Creating an environment for plug-ins

Mike's Notes

Here are my rough ideas about how to create an environment in Pipi 9 for plug-ins.

I want to reduce Pipi to its essential and closed core, and the remainder will be turned into open-source plug-ins available on GitHub. The community could then create other plug-ins and modules to extend the platform.

I would like to talk with people who have done something similar.

Resources

References


Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

11/05/2025

Creating an environment for plug-ins

By: Mike Peters
On a Sandy Beach: 04/03/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

From Wikipedia - "In computing, a plug-in (or plugin, add-in, addin, add-on, or addon) is a software component that extends the functionality of an existing software system without requiring the system to be re-built. A plug-in feature is one way that a system can be customizable.

Applications support plug-ins for a variety of reasons including:

  • Enable third-party developers to extend an application
  • Support easily adding new features
  • Reduce the size of an application by not loading unused features
  • Separate source code from an application because of incompatible software licenses
..."

I have been putting off creating a plug-in environment for Pipi 9 because it wasn't an urgent task.

However, recently, a representative of a large software company contacted Ajabbi about embedding their product on ajabbi.com web pages, which raised the issue of plug-ins. We talked, and now they are considering it.

I might have a first plugin to build, so I better figure out how to do this. :)

I am now working this out by the seat of my pants, and things will no doubt change a lot.

I did a lot of investigating when working on Pipi 6 (2017-2019), and I liked how OpenERP (Now Odoo) enabled community-sourced extensions (they call them addons) to its open SaaS product.

The Odoo addons are packaged using a sensible standard format.

  • manifest_py
  • readme
  • controllers/
  • data/
  • demo/
  • doc/
  • i18n/
  • models/
  • report/
  • security/
  • static/
  • tests/
  • tools/
  • views/
  • wizard/

Plug-in package

A package structure similar to Odoo and simple industry standard file formats would work, packaged in a zip file and including the following.

  • Name
  • Description
  • Author/developer
  • Icon
  • Manifest file (XML)
  • Sample data (SQL)
  • Language strings of any other language mapping to the base English string (CSV)
  • etc

Plug-ins and modules are quite different.

SaaS Module

  • SaaS applications are built out of reusable modules.
  • The admin web UI should be the only thing required to add or remove modules (tick boxes).
  • Modules follow domain-driven-design (DDD) principles.
  • Have an MCV architecture.
  • Examples:
    • Assets
    • Invoices

SaaS Simple Plug-in

  • Simple Plug-ins add simple UI functionality to a SaaS application and usually involve HTML.
  • Simple forms are used to add plug-ins.
  • CMS Examples:
    • Embed Google Map
    • Embed ESRI Map
    • Embed Mathematica Notebook
    • Embed Jupyter Notebook
    • Embed complex Java object

SaaS Complex Plug-in

  • Complex Plug-ins can work with third-party applications using methods such as databases, APIs, scripting, XML, and JSON.
  • The DevOps Engine (dvp) is required to configure integration.
  • Examples:
    • Office 365
    • Google Workplace
    • Zoho
    • Odoo

Pipi Plug-in

  • Pipi Plug-ins extend Pipi by adding 3rd-party software using wrapper and configuration settings.
  • The DevOps Engine (dvp)  is required to configure integration.
  • The plug-ins can interact fully with the engines and other Pipi objects.
  • Examples:
    • Docker
    • Database, e.g. semantic, graph, document
    • Another computer language, e.g. Prolog
    • Another API type, e.g. SOAP
    • Azure platform config
    • AWS platform config
    • GCP platform config
    • WolframAlpha
    • ESRI ArcGIS

Engines

  • The Plug-in Engine (plu) to register plug-ins is now being built.
  • The Module Engine (mdl) registers all modules.

Customer DevOps

Mike's Notes

Here are my working notes from day 9 of building the DevOps Engine for Pipi 9. 

Over the weekend, I attended an excellent film script workshop, but managed to work on the DevOps Engine when I wasn't supposed to. Often, I get more done by relaxing and not thinking about a problem. Then, these new ideas start interrupting.

Resources

References


Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

11/05/2025

Customer DevOps

By: Mike Peters
On a Sandy Beach: 03/03/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Today, I enabled a separate DevOps Engine for my first customer. Since they will use a multi-tenanted SaaS application, their DevOps engine will also be multi-tenanted.

In this case, their DevOps Engine setup is more about feature requests, customer support, configuration management and automated builds.

Creating a second, customised DevOps Engine helped clarify other practical problems that apply more broadly to building a front-end.

Steps

  • DevOps steps use standard workflow processes.
  • Moving between these steps uses transition conditions that can change states and trigger other asymmetric processes.

Multi-tenancy

By asking how the chosen tenancy model modified the Pipi instance, I clarified some assumptions and operational rules that result from using multi-tenancy rather than sole tenancy.
  • Multi-tenanted SaaS applications for SMEs will use a multi-tenanted Pipi in the back end, which allows less customisation.
  • Sole-tenanted SaaS enterprise applications will use a sole-tenanted Pipi in the back end, allowing more customisation.

Deployment

  • I figured out a simple way to automatically remove a customer deployment in a multi-tenanted situation, allowing Pipi to close an account.

History of DevOps

Mike's Notes

Some helpful background history to give context. Written by Ian Buchanan, Principal Solutions Engineer, Atlassian

Resources

References


Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

02/03/2025

    History of DevOps

    By: Ian Buchanan
    Atlassian: 

    How development and operations teams came together to solve dysfunction in the industry.

    Despite the rise of agile methodology, development and operations teams remained siloed for years. DevOps is the next evolution of collaboration tools and practices to release better software, faster.

    Bringing development and IT teams together

    The DevOps movement started to coalesce some time between 2007 and 2008, when IT operations and software development communities raised concerns what they felt was a fatal level of dysfunction in the industry.

    They railed against the traditional software development model, which called for those who write code to be organizationally and functionally apart from those who deploy and support that code.

    Developers and IT/Ops professionals had separate (and often competing) objectives, separate department leadership, separate key performance indicators by which they were judged, and often worked on separate floors or even separate buildings. The result was siloed teams concerned only with their own fiefdoms, long hours, botched releases, and unhappy customers. Surely there’s a better way, they said. So, the two communities came together and started talking – with people like Patrick Debois, Gene Kim, and John Willis driving the conversation.

    What began in online forums and local meet-ups is now a major theme in the software zeitgeist, which is probably what brought you here! You and your team are feeling the pain caused by siloed teams and broken lines of communication within your company.

    You’re using agile methodologies for planning and development, but still struggling to get that code out the door without a bunch of drama. You’ve probably heard a few things about DevOps and the seemingly magical effect it can have on teams: Nearly all (99%) of DevOps teams are confident about the success of their code that goes into production, in a survey of 500 DevOps practitioners conducted by Atlassian¹. 

    However, DevOps isn’t magic, and transformations don’t happen overnight. The good news is that you don’t have to wait for upper management to roll out a large-scale initiative. By understanding the value of DevOps and making small, incremental changes, your team can embark on the DevOps journey right away.

    Going beyond agile

    DevOps touches every phase of the development and operations lifecycle. From planning and building to monitoring and iterating, DevOps brings together the skills, processes, and tools from every facet of an engineering and IT organization.

    Agile methodologies help teams plan and produce by breaking work down into manageable tasks and milestones. Agile relies on sprints, backlogs, epics, and stories to assign work to skilled team members, adjust timelines when necessary, and deliver quality products and services to customers. Read more about agile.

    Continuous integration and delivery: Continuous integration and delivery is a cornerstone of DevOps practices that relies on automating the merging and deployment of code. Traditional development methods require engineers to manually update changes in the codebase, with additional manual checks to ensure quality code is ready to ship into production. Deployments are scheduled with weeks- or months-long delays to remove the likelihood of bugs or incidents. DevOps practices remove these delays by automating the merging, testing, and deployment functions. High-performing teams use CI/CD to reduce their deployment frequency from every few months to multiple times each day. Read more about CI/CD.

    Git repositories and workflows enable the automation and version control capabilities that are foundational to DevOps practices. Because Git is distributed, operations such as commit, blame, diff, merge, and log happen faster. Git also supports branching, merging, and rewriting repository history, which enables powerful workflows and tools. Read more about Git.

    IT service management is the process IT teams use to manage the end-to-end delivery of IT services to customers. This includes all the processes and activities to design, create, deliver, and support IT services. The core concept of ITSM is the belief that IT should be delivered as a service, which goes beyond basic IT support. ITSM teams oversee all kinds of workplace technology, ranging from laptops, to servers, to business-critical software applications. Read more about ITSM.

    Incident management teams respond to an unplanned event or service interruption and restore the service to its operational state. In a “you build it, you run it” model, developers partner with operations to reduce the likelihood of an incident occurring, and also reduce the mean time to recovery when an incident happens. Read more about incident management.

    State of DevOps

    Organizations and teams continue to adopt DevOps practices and tools. In a survey of 500 DevOps practitioners, Atlassian found that 50% of organizations say they’ve been practicing DevOps for more than three years.

    Unfortunately, despite agreement on the definition of DevOps and the benefits of implementing DevOps practices, organizations and teams still struggle to fulfill the promise of DevOps. Teams must focus on continuous feedback, iteration, and improvement to deploy better and faster to meet customers' needs.

    You can learn DevOps best practices with our Beginner's guide to DevOps. To put DevOps into practice, we recommend trying Open DevOps, which provides everything teams need to develop and operate software. Teams can build the DevOps toolchain they want, thanks to integrations with leading vendors and marketplace apps. Try it now.

    5 Authentication Features You Should Know

    Mike's Notes

    In last week's issue of Level-up Coding engineering newsletter, there was this article by Nikki Siapno, Engineering Manager at Canva and Co-Founder of Level Up Coding.

    "Level up your engineering and system design skills. Join the growing community of engineers who prefer our visual approach to software engineering." - Level Up Coding

    Resources

    References


    Repository

    Home > Ajabbi Research > Library > Subscriptions > Level Up Coding

    Last Updated

    01/03/2025

      5 Authentication Features You Should Know

      By: Nickki Siapno
      LinkedIn: 20/02/2025

      Authentication isn’t just about logging in.

      It involves multiple layers of security, user experience, and compliance. 

      Here are five auth features you should consider adding to your applications to enhance security and provide a seamless user experience:

      𝟭) 𝗟𝗼𝗴𝗶𝗻 & 𝗥𝗲𝗴𝗶𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻

      Includes secure credential storage, password hashing, and customizable user flows for seamless onboarding.

      𝟮) 𝗦𝗶𝗻𝗴𝗹𝗲 𝗦𝗶𝗴𝗻-𝗢𝗻 (𝗦𝗦𝗢)

      Lets users log in once and access multiple apps via OAuth 2.0, OIDC, or SAML.

      𝟯) 𝗠𝘂𝗹𝘁𝗶-𝗙𝗮𝗰𝘁𝗼𝗿 𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻 (𝗠𝗙𝗔)

      Adds a second layer of security with TOTP codes, biometrics, or push notifications.

      𝟰) 𝗣𝗮𝘀𝘀𝗸𝗲𝘆𝘀 (𝗪𝗲𝗯𝗔𝘂𝘁𝗵𝗻)

      Passwordless authentication using biometrics and device-native security for a seamless login experience.

      𝟱) 𝗠𝗮𝗴𝗶𝗰 𝗟𝗶𝗻𝗸𝘀

      One-time login links sent via email, eliminating the need for passwords while enhancing UX.

      𝗛𝗼𝘄 𝗱𝗼 𝘄𝗲 𝗶𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁 𝘁𝗵𝗲𝘀𝗲 𝗳𝗲𝗮𝘁𝘂𝗿𝗲𝘀?

      • Building from scratch is time-intensive, requires expertise in security, UI/UX, email systems, and compliance.
      • That's why 𝗮𝘂𝘁𝗵 𝗽𝗿𝗼𝘃𝗶𝗱𝗲𝗿𝘀 (CIAM solutions) like FusionAuth are so popular.
      • They 𝗮𝗯𝘀𝘁𝗿𝗮𝗰𝘁 𝗮𝘄𝗮𝘆 𝘁𝗵𝗲 𝘄𝗼𝗿𝗸 𝘄𝗵𝗶𝗹𝗲 𝗽𝗿𝗼𝘃𝗶𝗱𝗶𝗻𝗴 𝘂𝘀 𝗳𝘂𝗹𝗹 𝗰𝗼𝗻𝘁𝗿𝗼𝗹.
      • FusionAuth is an auth provider that I've been very impressed with. They provide:
      • 𝗖𝗼𝗺𝗽𝗿𝗲𝗵𝗲𝗻𝘀𝗶𝘃𝗲 𝗮𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻 & 𝘀𝗲𝗰𝘂𝗿𝗶𝘁𝘆 → Covers authentication, authorization, user and org management, and threat detection.
      • 𝗦𝗲𝗹𝗳-𝗵𝗼𝘀𝘁 𝗼𝗿 𝘂𝘀𝗲 𝘁𝗵𝗲𝗶𝗿 𝗰𝗹𝗼𝘂𝗱 → Unlike many providers, FusionAuth lets you develop, test, and deploy locally or in the cloud.
      • 𝗙𝗲𝗮𝘁𝘂𝗿𝗲-𝗿𝗶𝗰𝗵 𝗳𝗿𝗲𝗲 𝘁𝗶𝗲𝗿 → Generous free plan to get started without commitment.