In 1993, Apple shipped the Newton. A handheld, touchscreen, pocket computer that could read your handwriting. The idea was right, but in the technology of the day it was too cumbersome and too limited, and it never lived up to its potential. Years later, Apple realized the vision of the Newton when it redefined the smartphone and the tablet through the iPhone and iPad.
I think about the Newton a lot when I look back at our previous venture, Flux7 Labs. Flux7 broke ground in defining what a productized services firm is, but we did not have AI helping us, and many of our efforts fell short because of that. As a proto-AI-native services company, we were early. I want to share the lessons of Flux7's productization journey for today's tech services founders looking to transition into AI-native services.
What follows is the journey our IP took, and what each turn of it teaches now.
An Apple Newton MessagePad with a stylus beside a modern iPad, under the headline "Sometimes the right idea needs to wait for the right technology." Newton MessagePad photo by Felix Winkelnkemper, iPad photo by Evan-Amos, both licensed under CC BY-SA 4.0. This composite is likewise licensed under CC BY-SA 4.0.
Lesson 1: Your IP starts with your processes
When founders think about IP, they think about software. But IP starts with your processes. It is how your tools come together with your documentation into a machine for generating customer value. Documentation is the glue that holds it together, and we have written about our religious belief in it. It is what lets you scale quickly, improve gross margins by bringing on more junior people, and elevate everyone around them. The discipline was real. We invested hours into curation, kept a single source of truth, fought for discoverability, and enforced it from the top. We settled on GitHub wikis for accessibility, but we also ran a MediaWiki powered with plugins that pulled in live data, which we called Docboard.
AI changes the shape of this work. Docboard grew unwieldy and we moved away from it. The problem it solved is far easier now. You can quickly build software workflows around your knowledge, and especially in remote work, our information systems are already rich with the knowledge that used to live only in people's heads. You no longer solve discoverability and single source of truth by hand. AI systems can combine private knowledge bases, public ones, and live systems. Before you look at any other IP, look at what is documented, and what you wish were documented, and let that tell you what to build.
Lesson 2: Bridge architecture and implementation
The fundamental truth for a tech services company is this: unless you are in a position to tell your customers what to do, you are playing low-margin games. You have to own both solution architecture and implementation, turning mysteries into puzzles.
Unless you are in a position to tell your customers what to do, you are playing low-margin games.
One of the most respected market research firms told us they made more progress in a week with us than in nine months with the platform partner's professional services team. Patrick Kolencherry said from the AWS re:Invent stage that we had DevOps down to a science. Behind those moments was the clarity we provided translating business objectives into implementation. That clarity came from a refined, IP-backed assessment process. Our assessment platform let the solution architect run a guided conversation, make decisions fast, and set up the real engagement.
It did not scale as the solution architecture team grew. Eventually we replaced it with a reusable epicsDB. Both tools suffered from being glorified Google spreadsheets with queries and plugins. There were continuous demands to build them into a real tool, but we could not commit the resources. With AI, building it as a proper software product is a no-brainer. You bring the decisions together, couple them with knowledge bases, automate ingress from meetings and new engagements, and add self-service components so customers can engage independently.
With today's technology we should be taking it a step further, closer to what we did with Drawboard, our AWS architecture drawing tool, which focused on architecture clarity rather than implementation detail. We added a CloudFormation generator. We sunset that when AWS launched a competing tool and generating human-friendly CloudFormation grew too cumbersome. But now our best portfolio companies are all doing spec-driven development, starting the engagement with AI-generated prototypes and focusing the work on iteration and refinement. Very soon what we had as a vision will be table stakes.
Lesson 3: Align the business around your IP
Your core IP is what the whole business aligns around.
We started deploying Jenkins in every customer engagement. We loaded our own configurations and tools onto it, down to the detail of the green circle that had to appear on a successful job, and called it Fluxboard. It became part of every engagement. We built a Groovy library to stand up Jenkins pipelines for customers fast. That grew into what became our Gold Landing Zone, the GLZ, and we committed to it completely. Deploying the GLZ was part of new-hire onboarding. We staffed a permanent platform team to develop it. It featured in our sales conversations, delivered value early, and wowed customers. The IP worked because everyone lived and breathed it.
The IP worked because everyone lived and breathed it.
Products like the GLZ, which fuse the place your people work with your accelerators, are core to an AI-native services business running human-in-the-loop systems. Our biggest failure with it was not the product. It was how we sold it.
Lesson 4: Design the product around recurring revenue
The GLZ delivered recurring value. It was not structured around recurring revenue. We could have built it that way. Early on it would have required a commitment we were not ready to make, and by the time we were ready we were preparing for an exit, so the transition no longer made sense. It should have been sold as recurring revenue. That takes four things. We shied away from all of them. I recommend you don't, because AI has taken away every one of our excuses.
Training. With AI it is far easier to build better, simpler workflows directly into your IP.
Upgrades. A consulting firm cannot draw the hard line a product company draws, or it stops being able to serve its clients. We had to allow deviations, and that made upgrades too heavy a commitment to take on. AI lets you keep the customization and still keep every customer aligned with the latest version.
Bug fixes. The same as upgrades, only more critical.
Support. We never set ourselves up as an MSP. We would not compromise on time to resolution, which was the thing our customers complained about most with their own MSPs, and so we never built a support organization. Now, with chatbots and AI-driven systems, anyone can deliver tier-1 and tier-2 support at a very high turnaround.
Lesson 5: Deprecate like crazy
There was an undercurrent running through all of this, and it is the rule that ties the rest together. We have written about it before.
We had a pyplates-based library for writing CloudFormation templates that gave us CDK-like abilities years before CDK existed. When ServiceCatalog and Terraform rose, we accepted that the standard tooling, while not at our level, was good enough to build on. The same thing kept happening inside the GLZ. We replaced our own monitoring with AWS Config. We rebuilt the landing zone to be AWS Organizations native when Organizations arrived. Our IP changed constantly because the world changed constantly.
Do not make the mistake of holding onto what you have.
That work was expensive. Real DevOps engineering hours sank into building what we built, and it was painful and frustrating to throw away large chunks of code. But it was necessary. The IP you create now will be far cheaper to build and to replace. Do not make the mistake of holding onto what you have instead of taking the latest improvement. That is how you earn the recurring revenue.
What the journey taught us
In the past we wrote about building your services business as a machine. This post is about what the components of that machine's delivery engine look like. Your processes and documentation. The bridge from architecture to implementation. The IP the whole business aligns around. A product built for recurring revenue. And the discipline to deprecate it all and rebuild as the world moves.
Every one of these cost us money and time to learn, and each was gated by something that was expensive when we did it and is cheap now. The moves that took us years and serious capital are within reach of any founder willing to make them. AI has removed the excuses.
This marks a change in how we deliver and who we deliver to. That is exactly the question we are exploring in our roundtable next month, "New Markets, New Delivery Models." RSVP on LinkedIn here.