We finally crossed $1M ARR in February.

I wish I could say we crushed the original plan. We didn't.

We expected to get here about four months earlier, but growth went flat through most of Q3 and Q4 in 2025. Not dead. Not dramatic. Just... flat. That stretch forced us to get more honest about what was working, what wasn't, and where we were still operating like an earlier-stage company.

Why it took longer

The biggest lever was pricing, but it took way longer than I expected.

We spent close to a year planning it, testing options, talking to customers, and trying not to break trust in the process. This wasn't a quick "raise prices and hope" move. We wanted pricing that actually matched the value customers were getting.

When we finally rolled it out, it worked. That change pushed us over the line.

We grew up a bit

The pricing shift mattered, but it only worked because other pieces improved at the same time.

We put real effort into onboarding. Setup is clearer now, time-to-value is faster, and people are getting to useful outcomes earlier. That has helped both activation and expansion.

We're also maturing as a team and as a business. Bringing in growth leadership changed a lot for us, and I wrote more about that in No Longer a Solopreneur.

Moving upmarket on purpose

We removed our consumer-level plan and focused more on qualified businesses.

At the same time, we added more value to Standard and Business so those plans are stronger for the customers we want to serve long term.

We also tightened our sales process for qualified accounts. Better qualification, better discovery, cleaner handoffs. Less noise, more focus.

Agency partner program (early, but real)

We're still early here, but the agency/implementer partner motion is starting to come together.

A big part of this is giving partners better controls. Per-bot RBAC is one of those features that sounds small until you're managing multiple clients and teams. Then it becomes table stakes.

There is still a lot to build, but this channel is already showing promise.

2026 priorities

$1M ARR is a milestone. It isn't the finish line.

This year we're trying to push harder and build more leverage across the company, including a fuller team of AI agents supporting internal operations.

Our first AI "employee" already changed how we run parts of marketing and documentation. That alone has saved time and removed a bunch of repetitive work.

Current focus areas:

• Sales systems for larger, better-fit accounts
• Partnerships and agency growth
• Hyper-personalization for key customer segments
• Paid acquisition with tighter ICP targeting
• Building authority in specific, high-intent niches

Thanks to everyone who helped us get here. Customers, partners, team, friends, all of it.

We're just getting started.

-Aaron

As a founder, non-technical SEO was a new challenge for me. This post is my honest buildinpublic 1-year summary since getting serious about it. I'll share what worked, what didn't, and what you should focus on for your sites.

Content Marketing: A Mixed Bag

My first step was integrating headless WordPress into my NextJS site and jumping into regular blogging. We published 90 posts this year, a mix of:

• New product updates
• Relevant articles
• Case studies
• Tutorials

Most posts were AI-written with varying levels of human editing. Quality varies in my opinion. The results? Mixed at best.

What We Learned

• We get some traffic to the blog, with occasional spikes for timely articles (e.g., OpenAI announcements).
• Growth is stagnant despite our efforts.
• Most traffic goes to a small subset of posts on highly technical/niche AI topics.
• These visitors likely aren't our ideal customers.

My Take: Content marketing feels like a waste of time unless your product is super niche with low-competition keywords. The effort-to-reward ratio just isn't there for most businesses.

Documentation: The Hidden SEO Goldmine

Documentation turned out to be one of our easiest SEO wins. Here's why:

1. You have to write them anyway for your customers.
2. They're great for SEO.
3. Our DocsBot support chatbot crawls them daily, training itself to respond to customer questions.

Our Strategy

• We regularly analyze which docs are ranking well.
• We then optimize them further for keywords and add CTAs.
• We use a dual approach for titles:
  • H1 headers are customer-focused
  • Meta titles are optimized for search clicks for potential customers

Pro Tip: Don't neglect your documentation. It's a multi-purpose asset that can drive traffic, improve user experience, and even be a source to train an AI support bot.

Alternative Pages: Comparing Yourself to Competitors

Creating "alternative" pages comparing your product to competitors is table stakes for any SaaS company. Here's our approach:

1. We keep adding more competitor comparisons.
2. We use a consistent template but customize all content sections with the help of AI.
3. Each page features a comprehensive comparison table. This takes a lot of manual work to research, but it's worth it. And if you forget to keep it updated, it's not technically lying, right?

Benefits

• While they can be hard to rank organically, they're excellent landing pages for Google PPC ads.
• They train our AI retention agent to respond when someone is considering canceling to switch to a competitor.

Hack: Create an alternative page for your own product to capture users looking to switch away from you. Try to outrank your competitors' comparison pages, or even target it with PPC!

Programmatic SEO: Scaling Content Creation

We experimented with programmatic SEO using:

• A custom script
• Content template
• Unsplash API for images
• GPT-4 for writing with structured output json

The result? 300 landing pages for various industries. The hardest part was reviewing the output from the AI and making sure it was not hallucinating features or functionality that we don't have. Took a lot of context, prompt tuning, and reviewing to get good outputs.

Outcomes

• Indexing took time (tip: launch gradually)
• Most traffic goes to low-intent pages (e.g., "astrology chatbots")
• 1.7k clicks isn't bad for the effort involved

Next Steps: We plan to identify top-performing pages and add demo chatbots to enhance user engagement.

Free Tools: The Tip I'm Scared to Share

Intent is everything in modern SEO. Our biggest win came from creating free tools for searchers that:

1. Can't be instantly answered by AI (e.g., advanced calculators, checkers, converters)
2. Give users exactly what they want with no friction (e.g., no signup required)

This approach has been a game-changer for our SEO strategy. Here's why it works so well:

• High-Intent Traffic: We hit on several high-traffic, high-intent keywords, causing our traffic to explode.
• Developer-Friendly: As a developer, I can create multiple mini-products in a day, especially with AI coding tools like Cursor and GitHub Copilot.
• Quick Indexing: These tools are typically indexed within a week or two.
• Backlink Magnet: Useful tools naturally attract backlinks, more so than content. This potentially increases our Domain Authority (DA), helping other pages rank higher.
• Listing Sites: Launching these tools on Product Hunt, Hacker News, Reddit, etc. can generate additional backlinks from listing sites.

However, there's always room for improvement:

• Some tools have low search volumes or need keyword optimization.
• I should focus more on keyword research before building the tools, whoops.
• We need to test new strategies to better convert these leads beyond a custom CTA. Example: Add to email series in exchange for more usage credits.

Looking Ahead

SEO is an ever-evolving field, and what works today might not work tomorrow. However, focusing on user intent, providing genuine value, and leveraging your unique strengths (like development skills for free tools) can set you apart. That's what a year of hard SEO work at DocsBot has taught me anyway!

Remember, SEO is a marathon, not a sprint. Stay consistent, keep experimenting, and always prioritize providing value to your users.

P.S. If you're interested in training an AI chatbot for your business to handle customer support, team knowledge access, customer retention, RFP completion, custom copywriting, research, and more, check out DocsBot AI.

It took many trials, errors, and relentless perseverance, but I just reached $500k Annual Recurring Revenue (ARR) from all my projects combined! This journey shows the power of resilience, strategic positioning, and the magic of being at the right place at the right time. This post aims to share insights and lessons learned from launching eight products in six months, highlighting the importance of not giving up, putting oneself out there, and positioning yourself to ride the big technology wave when it comes.

The Struggle and the Breakthrough

The road to success was anything but smooth. I first launched Infinite Uploads back in 2021 after a year of work with a cofounder. Growth has been slow to flat for multiple years, and I didn't have the time or desire to put what was needed into it. But when the latest AI excitement started and the technology became available to build with, I began building new products furiously. I did not want to miss out on this wave. I launched eight different products in a span of just six months, but most were unprofitable or barely broke even. This period was marked by uncertainty, experimentation, and a relentless search for that one product that would resonate with the market. The struggle wasn't just about creating something valuable; it was about finding a fit in a market that's constantly shifting, especially in the world artificial intelligence.

Products That Didn't Quite Make It

1. Infinite Uploads: The first product I launched, a WP cloud storage SaaS, was a good learning experience but never gained significant traction. I sold it in 2024 for about 3x ARR.
2. Imajinn AI WP Plugin: The first AI image generator for WordPress that went viral on Twitter but almost no-one paid for.
3. Imajinn AI SaaS: The intent was to build a SaaS using newly available DreamBooth AI model custom training targeted at B2B. It was a good idea, but the tech was not ready, and the market was not there yet.
4. Imajinn AI Photoboot: I slighly pivoted marketing to target the B2C market with AI avatars and one-time payments, and made about $9k from it but consumer excitement was short-lived.
5. AI Sneaker Generator: A fun project that generated AI-designed sneakers. This was meant to be a lead magnet for Imajinn AI SaaS, and still brings in a lot of SEO traffic, but few conversions.
6. AI Children's Book: A fun project made with my wife and built on top of Imajinn AI SaaS, and my first try at ecommerce. Unfortunately, despite a lot of interest it's mostly only sold to friends and family. We did get featured in our local Dallas magazine and morning news TV show, which was fun.
7. AI Product Photo Generator: A free project that makes product photos look amazing with AI backgrounds. This was meant to be a lead magnet for Imajinn AI SaaS, and still brings in a lot of SEO traffic, but few conversions.
8. AI Couples Portraits: A fun project that generates printed AI portraits of couples. I built this to try to go viral for Valentine's Day, but despite spending a month on TikTok marketing and ads, it didn't take off. I sold like 3 ever.
9. DocsBot AI: The breakthrough came with DocsBot in February 2023, an AI-powered chatbot creator with many use cases like customer support and internal knowledge access. DocsBot was the product that resonated with the B2B market, and it quickly gained traction. The product-market fit was strong, and the demand was evident. DocsBot became the cornerstone of UglyRobot, driving significant revenue growth and propelling me towards this $500K ARR milestone.

Making My Own Luck

Success is often attributed to luck, but there's much more to it. It's about making sure you are in the right place at the right time. It's about creating opportunities and being prepared to seize them. For me, making my own luck meant not giving up despite the setbacks. It involved putting myself out there, connecting with potential users, gathering feedback, and iterating quickly. I have learned a little bit more each time launching a new product.

Some Key Lessons Learned

• Put yourself out there: Launching products is not just about building something great; it's about getting it in front of people. I learned the importance of marketing, community building, and networking to create buzz around my products. This was especially true for DocsBot, where I leveraged my network and connections to get the word out, and that eventually led to a viral tweet that brought in a lot of early customers.
• Power of the MVP: The minimum viable product (MVP) approach was crucial in my journey. With each successive launch I became less and less of a perfectionist. I was also often able to addon to or resuse code from the previous one speeding up development. It allowed me to quickly test ideas, gather feedback, and iterate based on user responses. This iterative process helped me refine my products and find the right product-market fit. Still, even with DocsBot my MVP was too feature-rich. I could have been first to market with a simpler product. Instead I lost millions in marketshare to a competitor who launched a simpler product a few days before me.

Riding the AI Excitement Wave

The timing couldn't have been better. The release of groundbreaking image and language models captured the world's attention, creating an unprecedented excitement around AI. By positioning DocsBot and my other projects within this wave, I was able to tap into a growing interest and demand for AI-powered solutions. Unfortunately most of the B2C products simply brought in waves of "AI tourists" who were not interested in paying for anything, just trying the shiny new toys. DocsBot's success was being able to capture the B2B market by providing actual ongoing value.

Building a Solid Foundation

Achieving this milestone is just the beginning. My next goal is to reach $1 million ARR. With a solid foundation now in place to build on, including systems, employees, and marketing flywheels, scaling up seems much more attainable. I still have a long way to go, but the journey so far has taught me valuable lessons that will compound and guide me in the next phase of growth.

Looking Ahead

As I look towards the future with an eye on the $1 million ARR goal, It's good to remember the lessons learned from those initial six months of product launches. As I continue on this journey, I remain committed to innovating, delivering value, and making my own luck every step of the way.

Our annual penetration test was due for DocsBot. I shared the first results on X, but the full workflow deserves more than a post.

I wrote about getting SOC 2 Type II certified last year. Certification was the milestone. This is the less glamorous part that comes after it: doing the work again, improving it, and collecting evidence that the controls are still real.

The traditional path is to hire a vendor, give them a target, and wait for a black-box scan. That can be useful, especially when you need independent validation. It can also be expensive, shallow, and disconnected from the people who have to fix what it finds.

This year I tried a different starting point.

I used Codex to test the system from both sides:

1. Source code first
2. Runtime behavior second
3. Auditor report last

That order matters.

The entire scan used around 6–7 million tokens, ran for 6–7 hours, found 37 issues ranked by severity, and produced a 50-page vulnerability assessment and penetration testing report mapped to our SOC 2 controls.

Then I used agents to help fix and independently verify all 37 findings.

When I was CTO at WPMU DEV, a project like this could have taken one or two months. This took hours of machine time plus my review.

Why start with the source code?

A black-box tester sees what an outsider can see. That is valuable, but it also means the tester has to discover the shape of the application from the outside.

Codex could begin with the map.

I used its deep security scan workflow to inspect the full application surface across our repositories. Different agents could take different slices:

• API routes
• Authentication boundaries
• File uploads and downloads
• Webhooks
• Billing flows
• Widget endpoints
• Server-side request forgery surfaces
• CORS and cookies
• Secrets and permissions
• Dependency risk
• Tenant isolation

This was not just grepping the codebase for scary strings and dumping everything into a report. The agents could trace a route, see how it was called, inspect the authorization checks, follow the data into storage, and compare the implementation with the intended security model.

The main agent then validated findings one by one.

That context makes a big difference. A suspicious pattern is not automatically exploitable. A route that looks protected in one file may be exposed by middleware somewhere else. A scanner can flag the pattern. An agent with repository context can investigate the path.

Then test the real application

Source review still leaves an important question: does production behave the way the code says it should?

After the repository scans, I had Codex test staging and production non-destructively. It checked the actual endpoints using the code analysis to decide what to probe.

The questions were practical:

• Can this route be reached without authentication?
• Can one tenant access another tenant's object?
• Do the live cookies and headers match the intended security model?
• Do upload and download flows expose anything they should not?
• Does runtime behavior match the assumptions we made while reading the source?

That last question is where shallow audits often fall apart.

Code review can miss deployment configuration. Runtime scanning can miss the path that would make a strange behavior exploitable. Connecting the two gives you a much more useful answer:

code → runtime behavior → exploitability → remediation → evidence

The economics were strange

The scan consumed enough tokens to sound ridiculous: roughly 6–7 million.

If I had paid directly for all of them, I estimated the model cost at around $200–$500. In practice, it used a large part of my weekly Codex allowance plus one of the limit resets I had banked.

That is still dramatically cheaper than a typical external pentest.

Cost is only part of the story, though. The bigger advantage was continuity. The same system that found an issue could explain the code path, propose a fix, retest the exploit, check for regressions, and turn the result into evidence for the audit.

The output was not a scanner export somebody would ignore in a spreadsheet. It was an engineering queue.

We fixed all 37 findings

Finding issues is the easy part. The value comes from closing them without creating new ones.

For each issue, or related group of issues, Codex helped run the same pipeline:

1. Create a separate worktree
2. Assign the fix to an agent in the correct repository
3. Keep the patch scoped to the finding
4. Hand it to a separate verifier agent
5. Have that verifier review the patch and test the exploit path
6. Iterate until it passed
7. Run our normal regression tests before merge
8. Finish with human review

The important rule was simple: the agent that wrote the fix should not be the only agent that approved it.

Many fixes went through three or four layers of review: implementation agent, verifier agent, security reasoning pass, regression tests, then my merge review.

Find the issue. Prove it. Patch it. Verify it independently. Test for regressions. Merge.

That loop is much more interesting to me than "AI found 37 vulnerabilities." Finding a pile of possible problems is easy. Turning them into verified fixes is the work.

What this does not prove

I would not tell every company to cancel its independent pentest vendor tomorrow.

An external tester brings independence, specialized experience, and credibility that your own agent run does not automatically provide. Your auditor, customer contracts, cyber-insurance policy, or compliance scope may specifically require a qualified third party. AI can also share the same blind spots across scanning, fixing, and reporting if you do not deliberately separate those roles.

For us, this was an affordable, repeatable security review and a strong evidence package for our annual SOC 2 work. It let us go much deeper before deciding where outside validation adds the most value.

The safest use of this workflow is not "the AI says we're secure."

It is:

• Give the agent broad visibility into the authorized system
• Keep runtime tests non-destructive and in scope
• Separate implementation from verification
• Require evidence for every finding
• Keep a human responsible for the final decision
• Bring in independent expertise where the risk or requirement calls for it

Coding agents are becoming security infrastructure

I used to think of coding agents mainly as a way to write features faster.

This project changed that.

A capable agent can become part of a repeatable security review system: map every surface, test each assumption, verify the findings, fix the code, retest the exploit, and produce an auditor-ready record of what happened.

It does not remove responsibility. If anything, it makes the responsibility more explicit because the human has to define authorization, scope, evidence, and the standard for "fixed."

But it changes what a small team can afford to examine.

Our first SOC 2 effort proved that a lean company could build a serious compliance program. This year's pentest made me realize the ongoing security work can become much more continuous too.

Not a point-in-time scan that goes stale in a folder. A loop we can run again.

That might be the biggest security benefit of coding agents: not one magical audit, but making careful review cheap enough to repeat.

I'm building a little robot to wear on my shoulder at conferences. I shared the first build thread on X, but there is a lot more to the story.

The first public test will be WordCamp US in Phoenix. I plan to mount it with magnets, walk around the conference with it, and let people talk to a physical DocsBot AI voice agent.

It listens through a microphone, answers through a speaker, changes its animated expression while it talks, and moves its head to feel a little more alive.

I have no idea how to build a robot.

But AI does.

That is what made this project irresistible.

From a description to a parts list

I started by describing how I wanted the character to look and behave. Small enough to sit on a shoulder. Retro, friendly, and obviously a robot. A square screen for a face. A head that could turn. A voice people could hear in a noisy room. Expressive enough to feel like a character instead of a phone strapped to a costume.

Then I bought roughly $50 of parts from Amazon and asked Codex to build it with me.

The core is an ESP32-S3 board with a 1.54-inch, 240×240 color display. It already has useful robot parts packed onto it: Wi-Fi, Bluetooth, microphones, touch, and motion sensors. I added a small external speaker, motors for movement, a controller board, wiring, and the other pieces needed to make the head and body work.

Normally, every one of those choices would send me into a week of datasheets, electronics forums, and half-working tutorials. Instead, I could show Codex the exact parts and ask it to reason across the whole system.

Which pins can safely be used? How should power be split? Where does the capacitor go? How do I keep a motor from pulling the voltage down and resetting the screen? What dimensions need to be reserved in the printed body?

The agent did not make physics disappear. It made the unknowns navigable.

Giving a square screen a personality

The face came first because that is the part people will actually connect with.

We built 15 expressions and behaviors for the tiny screen: idle, blink, speaking, waiting, smile, confused, surprised, love, wink, angry, crazy, sleep, and looks to the left and right.

I got absurdly specific about the face.

The eyes needed to be slightly bigger. The mouth needed to move lower. Then there was too much space between them. The surprised eyes were too large. The wink needed a slight rotation. The mouth bars were too thin at the sides. Blinks needed to happen less often and finish faster.

These are not normal engineering requirements. They are taste.

Codex could keep translating that taste into coordinates, transitions, timing, and drawing code until the character felt right.

The expressions now run on the real electronics. Codex combined my early face and voice experiments into one program that can join Wi-Fi, listen to someone speak, call the DocsBot Voice API, answer through the speaker, animate its face, and control the moving parts.

Watching all 15 expressions come alive on the actual screen was a bit of a Frankenstein moment.

Designing a body around parts I already bought

The physical body had to wrap around reality.

The screen determined the head dimensions. Buttons and the charging cable needed openings. The speaker and motors needed mounts. Wires had to pass through the neck. The head needed enough clearance to move without colliding with the body.

OpenSCAD turned those measurements into printable parts. Because the design was code, Codex could change dimensions, regenerate the model, and reason about whether the electronics would fit.

It could also check the movement in simulation before I committed to a long print.

Then Blender MCP gave me polished previews of the model before printing.

That brought taste into the physical build loop too. I could see when the face border felt too heavy, when the proportions drifted, or when the feet looked like clown shoes.

At one point my entire design feedback to Codex was, "Your arms and legs suck."

It was accurate feedback.

The render made weak choices obvious before they became plastic. Codex updated the OpenSCAD model, Blender rendered the next version, and I judged it again.

Then reality attacked

Software people get spoiled by undo.

A bad code change can be reverted. A bad 3D print sits on the desk for hours, consuming filament while teaching you about tolerances.

My first prints quickly reminded me that a simulation is not a workbench. Supports fuse to parts. Holes shrink. Wires take up more space than their diagrams. Cheap motors have opinions. A USB-C cable that looks flexible online becomes a structural component when you try to bend it inside a tiny body.

The body is ready to print, but it still needs its first complete assembly. Plastic tolerances and my assembly skills are the next boss battle.

Conveniently, the 3D printer doing this work is one I won at a previous WordCamp US. Now it is printing a robot to take back to WordCamp US. That feels appropriate.

AI coding agents have reached my workbench

The interesting part of this project is not that an AI wrote some embedded code.

It is that one agent could help across disciplines that used to be separate rabbit holes:

• Electronics and power
• Embedded software
• Wi-Fi and voice APIs
• Character animation
• Motor control
• Parametric CAD
• Physics and clearance checks
• Blender renders
• 3D-print preparation
• Debugging the assembled hardware

I still make the decisions. I decide whether the face feels friendly, whether a part is ugly, whether the movement is worth the complexity, and whether I trust the wiring enough to plug it in.

But I no longer need years of experience in every tool before I can attempt the project.

That changes who gets to make physical things.

AI coding agents started by helping us move pixels around a browser. Now mine is helping move a robot's head on my desk.

The deadline is a conference crowd

The first job for this robot is simple: start conversations.

At WordCamp US, someone should be able to walk up, speak to it, and hear a DocsBot voice agent answer through a physical character sitting on my shoulder.

Codex got the face, voice, and movement working on the actual electronics. OpenSCAD produced the printable body. Blender helped me reject ugly choices before printing them.

Now the design has to become plastic, survive assembly, attach securely with magnets, and spend a conference day moving through a crowd.

I fully expect to leave Phoenix with a new bug list.

But even if an arm falls off, this project already proved something to me. The gap between "I have an idea for a robot" and "there is a talking face on my workbench" is much smaller than it used to be.

AI didn't just help me code faster.

It helped me build something I did not know how to build.

I built a tiny robot for DocsBot and carried it around the conference floor.

It was a small, 3D-printed thing with a screen for a face, moving head and arms, and a speaker inside its body. I expected people to notice it for a second and then go back to whatever they were doing.

That wasn't what happened.

It felt like everyone loved it. Everyone wanted one. At one point I started wondering if we should sell these instead of AI agents.

It gave people an easy first question

People would stop and ask what it was, whether it could talk, how the head worked, and if they could build one. Those questions gave me a natural way to explain DocsBot without opening with a pitch.

The robot did some of the social work for me. A physical object is easier to approach than a person who looks like they are waiting for a sales conversation. Once someone asked about the robot, we had something specific to talk about.

It was a conference guide with a face

The robot was powered by DocsBot's voice AI agents. I trained it on the conference information so people could talk to it and ask about upcoming sessions, nearby restaurants, and the weather.

Those answers came from the same DocsBot building blocks we use elsewhere: training sources, Skills, and Actions. The robot could listen through its microphone, answer through the speaker, and animate its face while it talked.

That made the demo more useful than a prerecorded script. Someone could ask a question about the place we were standing in and get an answer from a physical DocsBot character.

The build became part of the product story

The robot is not a separate marketing prop. It runs DocsBot voice software on an ESP32-S3, uses a small iPhone and Apple Watch remote, and has a body built from printable parts. The face, voice, movement, wireless setup, and physical assembly all had to work together.

That made the conversations more interesting. People could ask about the software, then the hardware, then the process of putting the whole thing together. I could show them the actual object instead of describing a future prototype.

We got more value without a booth

We weren't sponsors and didn't have a booth. We still got more value out of most of the booths because people already knew who we were. Everyone who had any interest in DocsBot came over to talk.

I keep thinking about what that says about conference marketing. Doing a good job and creating something high-quality still matter, but they don't guarantee that anyone notices. The robot was cute, specific, and different from everything else on the floor. It gave people a reason to come over.

At a conference, being memorable can matter more than having the most polished thing in the room.

I open-sourced the build

The full project is now in the uglyrobot/docsbot-robot GitHub repository.

It includes:

• ESP32-S3 firmware with credential-free Wi-Fi setup
• The SwiftUI iPhone and Apple Watch remote
• Current STL files and editable OpenSCAD sources
• Assembly diagrams, print guidance, a parts list, and Amazon search links

I removed private Wi-Fi and service configuration from the public code. The repository also calls out the attribution requirements for the original articulated limb toolkit.

What I learned

The best conference demos give people a reason to walk over before they know what the product does. This robot made that happen over and over as I walked around the floor.

If you want to build one, start with the parts list and the assembly guide. The project is open source, so you can print your own version, change the colors, and make the robot your own.

That's how I feel sitting here, one day away from wrapping up what has been the most intense product sprint of my life. Twenty-plus new features launched. Fourteen detailed announcement posts. Nine emails. A live stream kickoff that got cut short by a thunderstorm and power outage. Daily bug fixes. Countless UX tweaks. And not much sleep.

The Hardest Step

Developers often think shipping means merging code. But the real step-the one that turns half-finished PRs into an actual product-is polishing. It's the part where you take raw functionality, add UX, define purpose, and wrap it all with clear messaging. You have to turn a feature into a useful product.

That step is slow and painful, and right now it's mine alone. As founder and product manager, I'm the bottleneck. Some of these features were started by our devs over a year ago. DocsBot Week forced me to finally finish them, test them, and ship them in a form that makes sense to real users.

Founder Mode

Every day was the same grind:

• Review old PRs, finish edge cases, fix bugs
• Decide the user-facing purpose and messaging for each release
• Work with our marketing team to build docs, posts, graphics, and emails
• Push live updates while mopping up problems from the previous day's launch
• Watch usage, collect feedback, tweak the UX, repeat

It was a forcing function-one that finally turned dusty branches into polished features.

The Marketing Machine

Product alone doesn't move the needle. So in parallel, I had to direct the marketing engine: coordinating schedules, approving copy, lining up social posts, and making sure the story of DocsBot Week held together.

Fourteen announcement posts and nine emails later, we had a full narrative arc. Each feature release built into the next. The content team worked fast and hard, but the weight of aligning product and messaging still sat on me.

Live Stream Chaos

We kicked off DocsBot Week with a live stream. It was going well… until Texas weather decided otherwise. Thunderstorm. Power out. Stream dead. Founder lesson: live streams suck.

We still got the launches out, but it reminded me why async content is safer than betting on live events.

Panic, Bugs, and Progress

Every daily launch came with last-minute bugs and unexpected UX friction. Feedback rolled in immediately, and I scrambled to adjust. Some nights I'd patch and re-deploy three times before the new features felt usable.

It was messy. It was stressful. But by the end of each day, we had taken another step toward making DocsBot a better product.

Looking Back

DocsBot Week more than flashy announcements. It was a forcing function. It took a year's worth of half-finished work and compressed it into seven days of actual shipping.

The result:

• 20+ new features live
• 14 announcements written
• 9 emails shipped
• Hundreds of bug fixes and UX improvements
• A team stretched, but stronger

I don't want to run another week like this anytime soon. But it showed me what's possible when the deadline is immovable and the scope is brutal.

DocsBot Week is done.

If you haven't yet, go check out the full list of what we shipped. Better yet, subscribe and see how DocsBot can transform your customer support, team knowledge, and daily workflows.

I'll be sleeping for the next three days.

-Aaron

Finding the Right Fit

Infinite Uploads was born during the COVID lockdowns, built to provide WordPress users with an easy, unlimited cloud storage and CDN solution. While the product has great potential, my time has been consumed by other more successful products like DocsBot, leaving little room to grow Infinite Uploads as it deserves.

So beginning of last year I started looking for a buyer. I wrote a detailed post announcing my intentions, and made it brutally honest, sharing all the numbers and challenges. I wasn’t super aggressive about trying to get the best value possible out of it. Instead, I wanted to find the right fit and someone who would appreciate and grow Infinite Uploads. I really wanted it to be in the hands of someone who I knew would take care of it and help it come to fruition in an amazing way because I think the product has so much potential. It just wasn’t something I had the time to focus on.

I shared on Post Status Slack and Twitter/X with all the big WP players and got a few leads but nothing came of it. It was either too small for them or too expensive for the single developer buyers. Ultimately it was via my X followers that I found a buyer. I began discussions with Blake Whittle of ClikIT. I had some wavering on if I should sell, and he was very patient with me, but ultimately I decided to go for it. The main sticking point was he did not have the cash up front for my asking price.

At WordCamp US, I connected with Blake. After doing an escape room and hanging out, I walked him through everything, he made an offer, and shortly after, we signed a Letter of Intent (LOI). Now the first thing anyone always asks is, Oh, how much did you sell for? How much money did you make? And I always hate when they don't provide those numbers. So I will say that I did post my asking price on my original post. And the offer was pretty close to my asking price (3x current flat ARR/net profit) but involved about a 40% down payment and a seller financing portion that would be paid out monthly over 3 years with no contingencies. After discussing with my wife, I signed the LOI, and Blake’s team began drafting the asset purchase agreement.

Structuring the Deal

Since Infinite Uploads is part of my holding company, UglyRobot LLC, we opted for an asset purchase rather than a full business sale. This included the code, IP, domains, customer base, social accounts, and other assets. The initial contract needed adjustments, including clear terms for payment delays or defaults on the financing. Tools like ChatGPT o1 helped flag potential issues and ensure clarity.

We also worked through IRS reporting requirements, which included preparing IRS Form 8594 (Asset Acquisition Statement Under Section 1060). This form is required for both buyer and seller in an asset sale to allocate the purchase price among the sold assets. Allocating assets properly is critical, as it can significantly affect tax outcomes for both parties. For example:

• The buyer may need to capitalize certain parts of the purchase over years (e.g., goodwill or IP), which aren’t immediately deductible.
• The seller may have parts of the sale taxed as ordinary income (e.g., software support contracts) versus capital gains (e.g., goodwill or IP).

This often-overlooked step is a key part of the negotiation and can have long-term financial implications.

Due Diligence and Documentation

After finalizing the agreement, we set a closing date of November 25th. I created a shared Google Drive for a "data room" to upload all necessary due diligence files, including:

• P&Ls and financials
• Recent invoices for costs
• Stripe reports
• Proof of ownership
• Documentation on Big File Uploads acquisition
• SOPs and updated code documentation

Closing Day

On November 25th, it all came together. Blake wired the down payment, and we skipped escrow to avoid hassle and costs, given our trust. We scheduled a live meeting with his team to transfer everything, including:

• Domains and DNS
• Cloud accounts
• Stripe account
• Other key assets

We encountered one minor DNS outage due to incomplete records in Cloudflare but resolved it quickly. A tip for future sellers: use separate accounts for your products to make ownership transfers smoother.

Announcements and the Future

The acquisition was announced by ClikIT and covered by WP Tavern. It’s exciting to see the product getting attention and heading into its next phase of growth.

Reflection

Now that I’ve sold my first business, does this officially make me an entrepreneur? While it wasn’t life-changing money, I’m thrilled with the outcome. Blake and his team are passionate about Infinite Uploads, and I’m excited to see the product grow under their care. Customers will benefit from better support and updates, and I’ll get to focus more on my main projects.

Infinite Uploads is entering its next chapter, and I couldn’t be more optimistic about its future. 🚀

Being a solo founder sounds freeing. You imagine full control, clear vision, and the ability to move fast without slowing down to align with anyone else. The reality is much heavier. Vacations never felt like vacations—I was still checking in on campaigns, assigning tasks from hotel rooms, and holding everything together even while trying to unplug. When big decisions came up, there was no one who truly understood the weight or the context to bounce ideas off. I could lean on friends or advisors, but it was still my call, my responsibility, and my sleepless night if things went sideways.

At DocsBot, our "team" until now has been my son, who I've been mentoring in marketing and entrepreneurship, plus a trusted bench of long-term contract developers and admins. They are all invaluable, but I remained at the center of every decision. Every project eventually funneled through me for approval, prioritization, or execution. If something stalled, it was because I hadn't nudged it forward yet. That kind of bottleneck is brutal when you're trying to build a category-defining product.

That changes now. I'm excited to share that @joshdailey is joining DocsBot as Chief Growth Officer, leaving WP Engine to join the future of customer support. Josh isn't just another hire; he's the person who can share the load, drive results, and own outcomes alongside me.

If you want to read more about the story behind this partnership, check out "From Treehouses to Tech: The Lifelong Friendship Behind DocsBot", a feature in The Repository highlighting how Josh and I went from building treehouses as kids to scaling DocsBot together. The piece dives into our long-running collaboration, the early experiments that paved the way for DocsBot, and why now is the right moment for us to team up again.

Why Josh?

Josh and I have history. We co-founded Infinite Uploads together during COVID (now acquired), where we learned how each other operates under pressure and uncertainty. We shipped product, handled support fires, and navigated growth during the strangest business climate imaginable. We were in the trenches together, and I know I can trust him when things get messy.

This summer he worked part-time with DocsBot, digging deep into the product, the workflows, and the customer journey so we could both be sure this was the right next chapter. He talked with customers, watched onboarding calls, and immersed himself in our roadmap. By the time we started talking seriously about a full-time move, we both already knew he was the right person—it was just a question of timing.

A few weeks ago he and his wife came to visit. We sat on the swing in my backyard and mapped out the details that would make him a true partner in the business: profit share, phantom equity, clear goals, and mutual expectations. We talked through how we'd make decisions, what success looks like at each stage, and how we can keep each other accountable. By the time the sun went down we knew it was time to make it official.

What changes for me

For me, this is both a relief and a turning point. I finally have a trusted partner to lead growth—someone to challenge and run with ideas, carry real weight, and care about the outcome as much as I do. It means I can take a real vacation without packing my laptop out of fear. It means the backlog of marketing experiments, strategic partnerships, and customer education initiatives no longer lives solely in my head.

It also gives me space to return to what I love most: building, strategy, and product. I get to spend more time working closely with our engineers, sweating the details of our AI stack, and shaping the experience that our customers rave about. Having Josh own growth means I can go deeper on the craft of DocsBot without sacrificing the company's momentum.

What changes for DocsBot

For DocsBot, it's the start of a new chapter. Josh is already laying the groundwork for a growth engine that is systematic and scalable: better analytics, sharper positioning, tighter feedback loops between sales, success, and product. He has a knack for telling the story of why DocsBot matters in a way that connects with founders, support leaders, and operations teams alike.

The market for DocsBot is massive. We and our competitors have barely touched it. Today we already have customers ranging from banks in Venezuela and law firms in Saudi Arabia to massive Japanese tech firms and car washes in Texas. Every business needs an AI agent that brings instant, 24/7, multilingual knowledge access for their customers or their team. Our job is to introduce them to what DocsBot can do, and now we have the leadership in place to do it at scale.

I'm energized for this next season. With Josh leading growth, DocsBot is better positioned than ever to serve customers who want reliable AI support that actually understands their business. And on a personal level, I'm grateful to no longer be doing this alone.

Here's to building the future—with a partner.

-Aaron

Not just a token increase either. I cut our lowest plan completely and bumped the price of our primary ICP plan by 50%. For a founder, it’s one of the scariest moves you can make. Your mind instantly goes to the worst‑case scenarios:

• What if customers leave in droves?
• What if growth stalls?
• What if we miscalculated the value our customers actually see?

But I also knew that the lowest plan wasn’t serving our business or our customers well. It attracted the wrong profiles—ones that cost more in support than they delivered in value. Meanwhile, our ICP consistently told us that the tool was saving them thousands through AI‑powered customer service. So I decided it was time to test whether the pricing was truly aligned with the value we provide.

The Results

Three months later, the numbers speak louder than any fear I had going in:

• Active subscribers: –2.6%
• MRR: +12.5%
• Churn rate: –14.7%
• ARPU: +15.5%
• Customer lifetime value (cLTV): +35.4%

Yes, subscriber count dipped. But MRR rose. Churn improved. ARPU jumped. And lifetime value surged — which changes the entire growth equation.

The Grandfathering Strategy

We chose not to force existing customers to the new pricing immediately. That shift will come next year. But something surprising happened: about 15% upgraded on their own.

Why? Feature gating. We started rolling out new features only to customers on the new plans. It wasn’t about punishing old users, but about rewarding the ones aligning with where the product is headed. The result: natural, voluntary upgrades without pressure.

Soon, we’ll launch an early upgrade campaign alongside more gated features that add real value, making the decision to switch even easier.

Why It Worked

The biggest lesson here: the right customers don’t balk at higher prices if the value equation is obvious.

Our ICP isn’t buying “software” — they’re buying outcomes. If a product saves them thousands, a 50% price bump barely registers. And by shedding misaligned customers, we can serve our best customers better.

The higher cLTV also opens a new lever: CAC. With stronger unit economics, we can confidently spend more to acquire even better customers, knowing they’ll stick around longer and return more value.

My Takeaway

Making the decision was far harder than living with the outcome.

Pricing is emotional for founders. It feels like you’re putting a price tag on your worth. But ultimately, it’s about alignment. When you line up pricing with the true value you deliver, everyone wins: customers get results, the business gets healthier, and you as a founder can grow without the constant fear of fragility.

This was one of the scariest steps I’ve taken with the business. And it turned out to be one of the most clarifying.

I believe the time has come. I've decided to consider the sale of Infinite Uploads, a unique cloud storage & CDN SaaS/WP plugin that integrates seamlessly with WordPress.

Launched by me and my co-founder Joshua Dailey (now at WP Engine) in January 2021 after almost a year of building during the COVID-19 lockdown, Infinite Uploads was born out of a vision to enhance WordPress users' experience by providing a simple unlimited cloud storage and CDN solution. Despite its potential for high growth and the unique features it offers, including a robust video encoding and hosting service, the time commitment to my most successful product, DocsBot AI, has led me to consider selling this venture.

Builder not a Marketer

It's been a remarkable journey since the inception of Infinite Uploads. I'm a builder and marketing is not my strength. Since the departure of my CMO co-founder over a year ago Infinite Uploads has just been on autopilot. This product has shown the potential to revolutionize how WordPress users manage their media content, and it pains me to see its potential wasted.

It could be a huge strategic opportunity for the right buyer to compliment their existing plugin suite or WordPress hosting service. The opportunity for significant expansion is undeniably there. I'm confident a simple dedicated marketing campaign or cross-promotion could rejuvenate its trajectory, pushing MRR far beyond $2,000.

A Unique Opportunity

Infinite Uploads stands as a unique opportunity in the WordPress ecosystem. It's not just a plugin but a fully SaaS product with recurring revenue, a sizable opted-in email list of 6-7k, and a suite of features that set it apart, including:

Cloud Storage and CDN

• A seamless integration with WordPress, allowing users to upload and manage files directly from the WordPress dashboard.
• Unlimited cloud storage and CDN solutions, with no file size limitations.

Video Encoding/Hosting

• GDPR-compliant, cookieless video hosting with no ads, tracking, or banners.
• A highly customizable player for branding, with no filesize limitations for uploads or storage right from the WP dashboard.
• Advanced encoding for compatibility across devices, with variable bit rate HLS streaming for optimized bandwidth usage and faster video delivery, all served from a CDN.

Big File Uploads Plugin

The sale also will include the Big File Uploads plugin with its outstanding 256+ five-star ratings and over 90,000 installs. We aquired this plugin in 2021 and it has been a great addition to the Infinite Uploads suite as a free lead generator and our main source of referrals and email subscriptions.

Assets

• https://infiniteuploads.com - site, code
• https://wordpress.org/plugins/infinite-uploads/ - Plugin and code
• https://wordpress.org/plugins/tuxedo-big-file-uploads/ - Plugin and code
• Associated domains, certs, branding, Github repos, social media accounts, Stripe account, etc.
• Email list of 6-7k

Tech Stack

• WordPress plugins - PHP, JS (partially jQuery, partially React), Bootstrap
• Website - WordPress website with custom plugin, Divi theme, SaaS API uses WP REST API
• We provision and interface with an S3-compatible object storage service
• Our CDN partner provides CDN services for storage, as well as the Video encoding and hosting and player
• AWS Batch on demand for long running jobs and crons like collecting usage stats, deleting files from cloud storage, etc. Jobs are written in PHP, packaged/deployed into Docker image via script ($2/mo AWS bill)

User Base and Revenue

Here are some key stats, as of February 2024. Once we open discussions and I know you're serious, I can provide more detailed financials and access to the Stripe account.

• $2k MRR
• $22k TTM
• 94% Gross Margin
• 17% YoY MRR growth
• 8.1% Churn rate
• 45.5% Trial to paid conversion rate

All of these numbers are with me putting in about 1-3 hours a month of support and no marketing.

Competitive Landscape

Our main competitor is WP Offload Media, which is a great product with 50k installs of their free version, giving some insight into the potential market. But WP Offload has seen a period of neglect, especially after its acquisition by WP Engine, which was primarily interested in Advanced Custom Fields (ACF) rather than enhancing WP Offload itself. This situation presents a significant opportunity for Infinite Uploads to capitalize on the gaps left by our competitors.

Additionally WP Offload is a freemium plugin, not a SaaS. It requires creating and properly configuring separate cloud and CDN accounts, where Infinite Uploads is a one-click solution. It also doesn't offer video hosting or encoding. There are a few other cloud storage plugins but none that offer the video hosting and encoding features that Infinite Uploads does. This positions Infinite Uploads additionally against products like VideoPress (Automattic), PrestoPlayer, Vimeo, and Wistia.

Valuation and Acquisition

Given these strengths and the plugin's quick growth potential, I'm seeking a valuation of around $75k as an asset purchase, hoping for an acquisition that appreciates the unique position Infinite Uploads occupies and its potential for rapid scale. I'm open to discussing the terms and structure of the sale, including a short transition period to ensure a smooth handover and continued growth. I'm also very open to creative deal structures and strategic partnerships that allow me to maintain a stake in the product and participate in its future success.

The Path Forward

For those interested in a SaaS product with strong foundations, immediate revenue, and significant growth potential within the WordPress ecosystem, Infinite Uploads represents an unparalleled opportunity. It's a chance to own a product that not only enhances WordPress functionality but also opens new avenues for revenue and user engagement through its advanced video features and large user base.

As I shift my focus towards nurturing DocsBot, I am excited to see where Infinite Uploads can go in the hands of someone ready to unlock its full potential. It's a bittersweet decision, but one that aligns with my vision for the future and the strategic focus required to achieve it.

For inquiries or to express interest in this opportunity, feel free to reach out. Let's discuss how Infinite Uploads can embark on its next chapter under your guidance, continuing to serve and expand its loyal user base.

if (interested_in_infinite_uploads) {
    reach_out_for_a_discussion('[email protected]');
    explore_the_potential_together();
}

I'm excited to see where this journey takes us. 🚀

I still remember where I was when I first thought: maybe SOC 2 isn’t just for big companies. I’d spent years pushing it aside — too costly, too vague, too “enterprise checkbox.” But this October, DocsBot is now SOC 2 Type II certified. You can see the announcement here: DocsBot is Now SOC 2 Type II Certified.

Here’s how we got there — the mistakes, the hacks, the surprises — from my POV.

The shadow of SOC 2

For a long time, SOC 2 was something whispered about in venture circles or huge SaaS orgs. It sounded like a standard for the security-obsessed, not for a scrappy solo founder or indie hacker.

I understood it should be about security. But it came from CPAs, not builders. In practice, it reads like a laundry list of “controls” — suggested security best practices — and the audit is about showing you did those things over time. Some controls feel outdated. Others are pure theater: checkboxes that don’t meaningfully improve security. You can even “modify” or weaken them if your context justifies it.

So I postponed. For years.

When I pitched to bigger clients, some didn’t care about security frameworks. They just asked me to fill out a Vendor Security Assessment / Questionnaire (VSA / VQA). Others wanted SOC 2 or walked away. I lost deals over “no SOC 2” more than once. But the cost of doing it often seemed bigger than the value.

Then our sales pipeline started growing. We got interest from enterprise-grade prospects. It was time to stop treating SOC 2 as an “optional extra.”

Choosing a path: Sprinto vs OneLeet

In my past life at WPMU DEV, I’d worked with Vanta. It’s polished but expensive and infamous for steep renewals. I didn’t want to get locked into that kind of surprise pricing.

I evaluated OneLeet (YC-founded, used by many early-stage startups) and Sprinto. OneLeet’s quote (after discounts) was around $6–8K/year. They said they’d hold prices flat for a few years. Reasonable, but still heavy on a lean budget.

Sprinto was cheaper ($4–6K). Less slick in UI and automations, sometimes quirky, likely managed from India. But their support approach is what sold me: whenever I hit a bump, they’d do a screenshare and walk me through the fix. That hands-on help is gold in compliance.

So I went with Sprinto.

Building from inside: roles, hacks, shortcuts

I wanted to avoid reinventing the wheel doing stuff by myself. So I enlisted my college-age son (studying business) to own policy writing, vendor agreements, training, subprocessor docs. He’s detail-oriented; I handled the tech, architecture, monitoring, tooling.

Because our team is small (a few employees plus contractors), adoption was manageable:

• Everyone signed policies, did annual training, installed device monitoring.
• Background checks: we had one new hire mid-process so I paid $29 for their check. For overseas or contractor roles, we set exclusions in policy where checks were unworkable.
• Many controls default to “manual pen test.” That’s expensive. Rather than skip, I used Astra’s Pentest-as-a-Service (a few hundred dollars). Not perfect, but it gave me a report I could show in sales conversations and satisfy part of the requirement.

Infra side:

• We rely heavily on IaaS (Vercel, Firebase). That means a lot of infrastructure security is outsourced.
• I use GCP’s built-in security and monitoring tools, GitHub Dependabot, cloud logging, etc.
• I’m the technical gatekeeper (I approve all code). That control is odd for SOC 2, which expects peer reviews. Instead of hacking out the control, I set up AI-based code review (OpenAI Codex + Cursor). I documented screenshots, the logic, the process. Auditor accepted it. Yes — AI reviewed my own code.

The timeline, audit, and surprises

• March 2025: I started planning and asking around.
• June: signed with Sprinto and kicked off.
• By end-August: controls mostly in place.
• To get Type II, you need at least a 90-day monitoring window.
• I solicited two auditor quotes. One was a better communicator, simpler process, far cheaper. We ended up paying $1,200.
• Audit began. Auditor got access to Sprinto, asked ~6 clarifying questions or asked for more screenshots, and within weeks finished the review. Because we had some controls in place earlier, they even backdated them.

What I thought would drag to end of year finished early.

The moment of triumph

When they told me “you’re certified,” I felt weirdly relieved. It wasn’t just validation. It was removing a barrier I’d loathed for years.

Now we’re live: DocsBot has a trust center (hosted by Sprinto), where clients can sign NDAs and access audit reports and security artifacts. You can read the official announcement here: DocsBot is Now SOC 2 Type II Certified.

Ongoing cost will probably settle around $5–6K/year (Sprinto + auditor renewal). That’s a price I’m comfortable paying for sales confidence.

Reflections (what worked, what I’d do differently)

What worked

• Choosing a compliance partner who helps you instead of leaving you lost in checkboxes.
• Delegating policy and paperwork to someone else (in my case, my son).
• Using mid-tier hacks (Astra pentest, AI code review) to satisfy controls without going full “enterprise budget.”
• Automating monitoring through platform tools (GCP, Dependabot, etc.) so less manual overhead.

What’s weird / still murky

• Some controls feel like theater (you’ll do them because they’re on the list, not because they’re threat-driven).
• You can argue or modify control severity in your context. The control framework isn’t absolute.
• Auditors vary hugely in style and price. The right auditor can drastically reduce friction.
• Renewal pricing is a gamble. That’s where many compliance platforms squeeze you.

Just got back from WordCamp US (WCUS) last week, and wow, what an experience! My wife and I decided to make the trip together this year, and it turned out to be an incredible journey both personally and professionally. Overall, we spent about $1,450 for the two of us to attend. We opted for a cheaper hotel a few blocks away from the main venue, which worked out great. Plus, we enjoyed free meals from all the after-parties and socials—can't beat that! We also snagged plane tickets on sale back in March, so planning ahead definitely paid off.

Pre-Event Preparations

Before the event, I wanted to make the most out of my time there. I booked around 20 meetings ahead of time. How? I used an X post with a calendar link—TidyCal is a cheap lifetime deal from AppSumo that's been super handy. I also DMed many X connections and even ran a sub-$20 X ad targeting WordCamp keywords. This strategy helped me line up meetings with WordPress business owners, @docsbotai customers, YouTubers, podcasters—you name it.

The Marathon of Meetings

The first day was intense—back-to-back meetings that were pretty exhausting for an introvert like me. But it was worth it. I also had about 10 impromptu meetings just by bumping into acquaintances from previous WordCamps, X followers, and floor introductions. The WordPress community is tight-knit, and it's amazing how many connections you can make in such a short time.

Valuable (and Sometimes Painful) Feedback

One of the highlights was getting valuable feedback on DocsBot from customers. Some of it was hard to hear but essential for improvement. I walked them through how to enhance AI support responses and expand usage across more products and use cases like pre-sales, retention, and copywriting. I also gathered a number of reviews and case studies that I can use for marketing. This face-to-face interaction is something you just can't replicate online.

Networking and Potential Partnerships

I had some exciting conversations about potential partnerships, including one with a big WordPress host that shall remain nameless ;-). Learned some influencer marketing tips from YouTube's craylormade, which was enlightening. I also asked many pointed questions about what marketing channels are working for fellow entrepreneurs and B2B sales. Probably will be able to book two or more podcast appearances from the connections this week.

A Significant Milestone: LOI for Infinite Uploads

I've been in talks for much of the year with someone interested in acquiring Infinite Uploads, my first WordPress SaaS. We even did an escape room together, which was a fun way to get to know each other better. Came away from the trip with a Letter of Intent (LOI)—we'll see how that works out, but it's a significant step forward.

Personalized Gifts with a Twist

I wanted to bring gifts but didn't want to do the usual swag. So, I trained a Flux AI model on their online images to generate fun pics of them in various styles, including their products and the WordPress logo. Printed them out to hand out—it was a great laugh and even got some shares on social media!

Fun Moments and Personal Connections

Picked up my annual favorite shirts at the Gravity booth and chatted about my trademark struggles with Carl Hancock. it's amazing how just following each other on X opens doors—you feel like you know the person already. Got to wow Mark, the founder of WordFence, with a demo and talked AI. Love geeking out and building these relationships you could never achieve via cold outreach.

Attending Sessions

Believe it or not, I only went to three sessions:

1. WPAI to see what my fellow AI fanatic @jameslapage has been working on.
2. Gravatar to support @ronnieburt with some well-planted questions.
3. The Brand session to get some unofficial legal advice on my trademark issues.

Each was valuable in its own way, and I'm glad I chose quality over quantity when it came to sessions this year.

Quality Time with Old Friends

Hung out all week with some of my favorite old @wpmudev coworkers. Bought way too many shoes at the Nike store with my best bud Joshua Dailey. Also, I never want to see another Voodoo donut until maybe next year. It's these personal moments that make the trip memorable beyond just business.

My Wife's Role and Support

My wife got to learn and practice her DocsBot elevator pitch and was a great support throughout the event. She came away with a renewed interest in helping more with the business. I'm determined to turn her into the next great B2B AI influencer!

The Takeaways

Overall, WCUS was a huge success. I think it's a much better investment than sponsoring a small booth where you're stuck all week. If you can be super strategic with your time to connect as much as possible, the ROI is incredible. In-person connections are more valuable than months of work on social media; combine the two for some amazing synergy!

For $1,450, I Came Away With:

1. Probably 2+ big customers and likely much expansion revenue.
2. Lots of feedback on my product to guide its development.
3. Potential influencer partnerships/affiliates.
4. At least two podcast bookings.
5. An LOI for the acquisition of my first SaaS!
6. New marketing ideas to implement.
7. And lots of friends and ongoing connections.

Moving Forward

Now, I just have to do better than last year at following up, closing deals, and keeping up the relationships! The real work begins after the event, and I'm excited to see where these new opportunities lead.

Thanks for reading! If you attended WCUS, I'd love to hear about your experience. Feel free to reach out on X @uglyrobot.

My sister needed a website.

She had already bought a domain and WordPress hosting, which sounds like most of the job should have been done. Instead, she logged in and found around 50 plugins preinstalled, upgrade notices everywhere, and a dashboard that assumed she already knew what half of it meant.

She couldn't figure out how to build the site.

I've worked with WordPress for more than 15 years. I built plugins, helped grow WPMU DEV, and made a career out of solving WordPress problems. So naturally, she asked me for help.

I opened the setup and had an uncomfortable thought: I didn't want to build her site with WordPress either.

Ten minutes later, she had a fast static site running on Cloudflare Pages, built with a few prompts in Codex using the ChatGPT subscription she already paid for.

Here is the finished site.

The problem was not WordPress itself

WordPress can still build almost anything. That is both its strength and its problem.

My sister did not need almost anything. She needed an attractive home for her writing, speaking, coaching, books, and contact information. It needed to be fast, secure, inexpensive, and easy to update a few times a year.

The hosting company had given her a toolbox full of choices before she had made a single decision:

• Which theme?
• Which page builder?
• Which form plugin?
• Which SEO plugin?
• Which security plugin?
• Which backup plugin?
• Which of the 50 preinstalled plugins were useful, paid upgrades, or just clutter?

That flexibility was not empowering her. It was transferring every product decision to her.

WordPress used to feel like the shortcut. For this job, it felt like the long way around.

I gave the agent the whole job

I didn't start by asking Codex to make a pretty homepage.

First, I gave it my sister's name and existing online presence and asked it to research her work. It collected the themes she writes and speaks about, the audiences she serves, her books and resources, and the way she already describes herself online.

Then it proposed the information architecture and content plan before writing code.

That ordering mattered. A website is not a pile of components. It is an argument about who someone is, what they do, and what a visitor should do next.

Once the plan looked right, Codex built the static site, connected the assets, and deployed it to Cloudflare Pages. No database. No plugin updates. No WordPress admin. Almost no attack surface.

The result was not merely "AI made a landing page." The useful part was that one agent could move from research to positioning to content to implementation to deployment without dropping the context between five different tools.

The update experience changed too

The biggest win is not that I built it in ten minutes. The biggest win is how she can maintain it.

When she wants to add a speaking event, change a paragraph, or publish a new resource, she does not have to remember where that setting lives. She can tell ChatGPT what she wants changed in normal language.

The implementation becomes a detail handled by the agent.

That is a completely different interface for owning a website. Instead of learning the tool's mental model, she can describe the outcome.

For a site that changes occasionally and does not need complex dynamic features, that feels much closer to the original promise of a website builder.

The post hit a nerve

When I shared this on X, the response was much bigger than I expected.

Some people saw it as evidence that WordPress had become too complicated. Others correctly pointed out that my sister had a hidden advantage: her brother knew how to choose Cloudflare Pages, set up the repository, review the output, connect the domain, and fix anything that broke.

One essay responding to my post called this the "duct-tape era" of AI website building. I think that criticism is fair.

My sister did not suddenly become a developer. She got a technical person to set up an agentic workflow for her. If the deployment breaks in a strange way, she is still probably calling me.

But that does not make the shift unimportant.

The amount of technical help required dropped from "build and maintain this website for me" to "set up a reliable path once, then let me request changes myself." That is a huge reduction in dependency, even if it is not zero.

Why not WordPress?

This is not my obituary for WordPress.

If my sister needed memberships, ecommerce, editorial workflows, a large plugin ecosystem, or a nontechnical agency that could take over tomorrow, WordPress might still be the right answer. It remains one of the most capable and transferable platforms on the web.

But capability is not the same thing as fit.

For a simple personal or small-business site, I now ask different questions:

1. Does this need a database at all?
2. Will the owner actually use a visual admin interface?
3. Could an agent safely make the few changes they need?
4. Who owns the system when the agent gets stuck?
5. Are we choosing a platform for today's job or for every imaginary future job?

For Elisa's site, a static build plus an AI coding agent was the simpler product.

That is the part I think the WordPress community should take seriously. The competition is not only Wix, Squarespace, Webflow, or another CMS. The new competition is a conversation that produces and maintains exactly the software someone needs.

The old question was, "Which website builder should I learn?"

The new question might be, "Why should I have to learn the builder at all?"

I spent a big part of my career helping WordPress democratize publishing. I still care deeply about that mission.

But on this project, the most democratic option was not teaching my sister another dashboard. It was letting her describe what she wanted and giving the agent the keys.