The short version: I got annoyed. The longer version is about marketplace fees, 20+ years of building software, and a question I can't stop chewing on about which other industries might be sitting ducks as software development keeps changing.

The marketplace fee that broke me

My fiancée runs a small wellness practice, and like most practices, we used a booking platform to handle scheduling and payments. We started out on a service called MassageBook, which is a dominant player in the massage niche and, to be fair, does a LOT right.

But the model has a catch I couldn't unsee once I saw it: the marketplace. Your booking page lives inside their directory, alongside every other therapist in your zip code. When a client finds you through that marketplace, you pay a cut. And the whole thing quietly nudges your clients, the ones you earned, toward a listing where your competitors are one tap away.

I kept thinking about what I was actually paying for. A monthly fee, plus payment processing, plus a commission, for the privilege of having my own clients shown a menu of other people they could book instead. That's not a tool working for me. That's a tool renting me access to an audience I already built.

I'm not here to dunk on MassageBook. The marketplace model makes total sense for MassageBook, and for plenty of their customers. It just doesn't make sense for the solo practitioner paying into it. That gap, between what the software optimizes for and what the person using it actually needs, is the whole reason ApptOnly exists.

The problem was bigger than my annoyance

Once I started looking, the annoyance turned into a market study.

Most booking platforms in this space (MassageBook, Vagaro, Fresha, Mindbody) are built for businesses with multiple staff. Teams. Front desks. Different rooms. But roughly 73% of massage therapists in the U.S. are sole practitioners. No staff, no front desk, no team. They're being sold software designed for a business they don't run, and charged for features they'll never use.

Some problems hit the solo operator a lot harder than they hit a bigger business. A massage therapist physically cannot answer the phone mid-session, because their hands are, you know, occupied. Their sessions are long, so a single no-show can wipe out a quarter of the day's income. Many of them work in Spanish, or serve Spanish-speaking clients, and not one major platform offers a genuine bilingual experience. These aren't edge cases. They're the center of the market, and they're underserved.

So the opportunity wasn't "make a slightly nicer MassageBook." It was "build the thing that should have existed for solo practitioners all along."

Why I figured I could actually pull this off

I've been making software for a long time. Long enough to have watched a few technology bubbles inflate and pop. Long enough that I've shipped more apps than I can cleanly remember. I know how the pieces fit together, what scales, what breaks, and what's worth not building in the first place.

But experience alone wasn't the advantage. The advantage was that I'm living the problem. Our practice, Body Balance by Marybel, became the pilot site. Every product decision got pressure-tested against a real, operating massage business instead of a persona in a slide deck. When I wondered whether a therapist would actually use something, I didn't have to guess. I could walk into the other room and ask.

The best vertical software almost always comes from someone who lived the problem first. I just happened to be a software guy who's marrying into the exact problem I wanted to solve.

How AI accelerated the build, and what it didn't do

Now for the part everyone wants to hear about, since I usually write about AI-assisted development here anyway.

Yes, AI made this dramatically faster. A solo founder building a full SaaS booking platform, with payments, intake forms, automated reminders, a white-label client-facing site, and a bilingual interface, would have been a year-plus slog a few years ago. With AI in the loop, I compressed enormous chunks of that. Scaffolding, boilerplate, the tedious 80% that used to eat weeks. It's a genuinely thrilling time to be building.

But here's the honest part, and it's the same point I made when I wrote about vibe coding: AI collapsed the time, not the judgment.

Every decision that actually makes ApptOnly good came from experience, not a prompt:

• Killing the marketplace entirely. The single most important product decision was a subtraction. No AI suggested that. It came from being on the wrong end of the fee.
• Bilingual EN/ES as a foundation, not a toggle. Most platforms bolt on a language switch. We designed for Spanish-speaking practitioners from the first screen, because I could see who was being ignored.
• Cutting features that sounded great but weren't feasible. When we scoped the financial tools, AI was happy to help me design a system that moved money between accounts. Domain knowledge is what told me that originating those transfers drops you into money-transmitter licensing: surety bonds, federal exposure, the works. So we architected around it. The software reads, calculates, and prompts, but never touches the money. That's a call you make from scars, not from autocomplete.

AI is the best junior developer I've ever worked with. Fast, tireless, never complains about indentation. But it doesn't know which thing is worth building, and it doesn't know what it's like to pay a commission on a client you brought in yourself. That part's still the human's job, and honestly, that's where 20+ years of doing this earns its keep.

What makes ApptOnly actually better

Stripped down, ApptOnly wins on a handful of things the incumbents structurally can't or won't match:

• No marketplace, no commissions. Your clients are yours. You keep 100% of what you earn from them. There's no directory quietly showing them your competition.
• Built for one, not for a team. No paying for multi-staff scheduling, payroll, or inventory you'll never open.
• Genuinely bilingual. Onboarding, dashboard, and the client-facing booking page, all in English and Spanish.
• No client app download. Your clients book from a link. No account to create, no app to install, which matters a lot when your clientele skews older or less techy.
• Your brand, not ours. White-label from day one. The booking page is yours, not an ad for the platform.
• Built for the work, by profession. Intake forms, client history, and preference sets are native, and they go beyond massage. A nail tech tracks color and shape preferences. A hairstylist tracks formulas and past services. A massage therapist tracks pressure and problem areas. Same engine, tuned per trade, instead of a generic notes field everyone has to bend to fit.

None of these are flashy. They're just right for the actual user, which turns out to be most of the battle.

Wait, is this only for massage therapists?

Fair question, since I keep saying "massage." Short answer: no.

ApptOnly started in massage therapy because that's the problem I live, and starting narrow is how you build something that actually fits instead of something vaguely OK for everyone. But the core need is shared across a huge range of trades: a solo professional who books one-on-one appointments and wants to own their client relationship.

Nail techs. Hairstylists. Estheticians and facialists. Lash artists. Body sculpting and lymphatic drainage pros. Mobile and in-home providers of every kind. Anyone running a one-person, appointment-based practice hits the same walls. Software built for teams they don't have, marketplace fees on clients they earned, and a booking experience that demands an app download nobody wants.

That's why the preference sets are built per profession rather than hardcoded for massage. The platform speaks each trade's language. If you book clients one at a time and your name is the brand, ApptOnly is built for you.

The question I can't stop asking

Here's where my brain went after all this, and it's the real reason I sat down to write.

If a solo developer with domain knowledge and a stack of AI tools can build a better product than the dominant player in a niche, in evenings, around a day job, then how many other industries are sitting on the same setup?

Think about the pattern. A big, established incumbent. Pricing that's crept upward year over year. A product that's bloated for the average user because it's chasing the enterprise account. Fees that feel less like a price and more like a toll. A customer base that's loyal mostly because switching is a pain, not because they're happy.

That describes a lot of software. Probably some you use today and quietly resent.

What's changed isn't that incumbents got worse. It's that the cost of building a focused, modern alternative has collapsed. The moat used to be the sheer effort of building, and AI drained a good deal of that moat. What's left as a real advantage is the thing AI can't give you: knowing the customer cold, and having the judgment to build the right thing instead of everything.

I don't think ApptOnly is a one-off. I think it's an early example of a pattern that's about to play out across a lot of overlooked verticals. The opening belongs to people who actually understand a specific customer's pain, not to the biggest team or the deepest pockets.

Which industry would you try to disrupt if you had the chance? I've got a short list of my own, but I'd rather hear yours. Drop it in the comments.

And if you're a massage therapist, nail tech, hairstylist, esthetician, or anyone who books clients one at a time and is tired of paying to reach the clients you already earned, that's literally why this exists. Come take a look at ApptOnly.

A few quick questions people have asked

What is ApptOnly? A booking platform built for solo practitioners who run on one-on-one appointments: massage therapists, nail techs, hairstylists, estheticians, lash artists, and other independent wellness and beauty pros. It includes branded booking pages, profession-specific intake and preference forms, automated reminders, payments, and a bilingual EN/ES experience, with no marketplace commissions and no required client app download.

Is ApptOnly only for massage therapists? No. It started in massage therapy because that's the founder's own practice, but it's built for any solo professional who books appointments and owns their client relationship. Preference and intake forms are tuned per profession: color and shape for nail techs, formulas for stylists, pressure and focus areas for massage therapists.

How is it different from the established booking platforms? ApptOnly has no marketplace, so there's no commission on your own clients and no directory exposing them to competitors. It's built for one-person practices instead of multi-staff spas and salons, it's genuinely bilingual, and it's white-label, so it's your brand on the booking page, not the platform's.

For example: Codex, from OpenAI, is a coding agent designed to deeply understand your codebase and follow project-specific instructions using natural language. It works especially well when guided by AGENTS.md files in your repository (more on that below).

Codex was released last week. This week, GitHub announced major updates to Copilot with the introduction of Copilot Workspace, which takes assigned Github issues, spins up a development sandbox, and submits a PR with its results - almost like pairing with an AI engineer who knows your repo. I think this one has a good chance of massive adoption since it's already built into Github, where developers already live.

Visual Studio Code also announced that they’re becoming an open source AI IDE. They also now have "Agent Mode". That move feels like a direct response to Cursor, which has quickly gained traction by being AI-native from the start (and is a fork of VSC).

And just today, OpenAI announced the acquisition of LoveFrom.ai, Jony Ive’s AI hardware startup. The goal? Build consumer AI devices that are more intuitive and beautiful. The human interface layer for LLMs is going to be extremely important, and OpenAI just brought an absolute icon into the fold.

Despite the dizzying pace, this level of competition is a net positive for developers and software in general. Tools are getting better fast and the way we work with code is fundamentally changing.

Anyway, one thing I particularly liked in Codex is how it uses AGENTS.md files to guide its behavior:

Codex can be guided by AGENTS.md files placed within your repository. These are text files, akin to README.md, where you can inform Codex how to navigate your codebase, which commands to run for testing, and how best to adhere to your project's standard practices.

This is a clean concept. You place guidance where it’s contextually relevant, right alongside the code it refers to. It’s efficient, it’s easy to find, and it just works.

I also like how Cursor handles this with their .cursor/rules directory. You can set rules to be Always, Auto Attached, Agent Requested, or Manual, which gives you a clean and modular way to define how agents should behave.

At Quiltster, we’ve already invested in building a good set of Cursor rules. We’re also interested in giving Codex a try, but maintaining two sets of agent instructions sounds like a headache. So, we added an AGENTS.md file to our repos that tells agents to reference .cursor/rules for its instructions.

Here’s what it looks like:

# AGENTS.md

This project uses Codex-compatible agents (e.g., in Cursor) to assist with development, refactoring, and maintenance. To ensure consistent, context-aware behavior, all agents must follow the directives below.

---

## 🔁 Runtime Behavior for Agents

- **Always load and interpret all files in `./cursor/rules/` on every request.**  
  These files contain high-priority, agent-specific instructions and overrides that influence behavior, coding style, architectural decisions, and task-specific guidance.

- Treat every file in `./cursor/rules/` as essential context, regardless of file type or naming convention.

- Files in `./cursor/rules/` may:
  - Override or extend project-wide conventions
  - Define specialized behavior for a specific domain, app, or tool
  - Include instruction sets tailored to agents or Codex-like systems

- Do **not** proceed with code generation, refactoring, or architectural recommendations without evaluating the current contents of that directory.

---

## Agent Execution Guidance

- Look for `.md`, `.json`, or `.py` files within `./cursor/rules/`; all may contain logic or instructions for agent use.
- Assume that any file in the directory is actionable unless explicitly marked otherwise within the file.
- When files contain overlapping rules, follow the most specific applicable instruction set based on file naming and structure.

---

## Agent Initialization Sequence

When responding to a request:
1. Load and parse all files in `./cursor/rules/`
2. Combine guidance from this `AGENTS.md` file with rule-specific logic
3. Apply instruction sets before generating or modifying any code
4. Use the combined ruleset as authoritative, unless explicitly overridden by user instructions in-session

---

## Maintenance Notes

- The `./cursor/rules/` directory may evolve over time. Agents should always load the latest version during each execution.
- If the directory is empty, fall back to global defaults and instructions in this file.

---

## Developer Guidance

If you're writing rules for AI agents:
- Place them in `./cursor/rules/` and commit them with clear names and versioning
- Use plain Markdown, JSON, or Python files
- Document the intent, scope, and override behavior within each file

---

This `AGENTS.md` file should be interpreted as high-priority guidance. When used with Codex, Cursor, or any AI-assist tooling, this file governs the expected behavioral contract between human collaborators and AI agents.

Upon querying Cursor, it seems to understand these instructions very well! I provide this example because this is general enough for anyone to use. However, I'd like to point out that the contents were (perhaps obviously) written by ChatGPT. LLMs are surprisingly great at writing these kinds of structured instructions, so don’t hesitate to generate your own based on your repo’s specific needs.

If we ever add contextually-placed AGENTS.md files in our repos, we’ll also update our .cursor/rules to treat those as high-priority inputs. For now, this setup strikes a good balance between clarity and flexibility.

At least, that's how we're doing it for NOW. Things are changing so fast that this could all look different next month. 🙃

The whirlwind of activity makes this an exciting time to be in software. It reminds me of the iPhone and early Web 2.0 years. Paradigms are shifting, interfaces are taking new directions, and there’s lots of room for invention and competition. I’m completely here for it!

Lately, there’s been a lot of noise around the idea of “vibe coding.” You’ve probably seen the posts:

I vibe-coded this app over the weekend… developers are cooked!

It’s the kind of hype cycle we see every time a shiny new tool or paradigm shows up in tech. And to be fair, AI really can accelerate development in ways that feel borderline magical. It’s a thrilling moment to be part of.

But let’s be clear: most of what people are showing off right now are demos, prototypes, or MVPs. AI agents today aren’t building complete businesses, shipping full platforms, or replacing developers. Yet.

As things are today, vibe coding works great in the early phases of a project, when speed and experimentation matter most. But building a reliable, secure, scalable service still requires humans who know how the pieces fit together. Trying to vibe code your way through a serious product is a fast track to technical debt and integration headaches.

This reminds me a lot of the no-code movement. No-code tools make you feel incredibly powerful in the early stages. You can spin up something fast, get it looking slick, and show off a working demo. But as soon as you need to handle something beyond the basic use case—like connecting systems together, dealing with edge cases, or fine-tuning performance—you quickly hit the limits of what the tool can do. What once felt magical starts to feel brittle and confining.

There is a reason that no-code platforms have not eliminated developer jobs. I believe it will be the same with AI -

Even the simple website you’re reading this on has multiple integrations: Supabase, Mailgun, Sentry, custom auth. I used AI extensively to accelerate the build, but at every step, the system was guided by an engineer (me) who understands the architecture, the risks, and the trade-offs.

We’ll get to a place where AI agents can handle more of that heavy lifting. But we’re not there yet. And no amount of hype will change that reality.

Don’t let the noise convince you that vibe coding is a shortcut to production-quality work. Use it for what it’s great at—then bring your engineering brain to the table.

Side note: I've been having fun making images for my blog posts using ChatGPT. Some of the things it comes up with are hilarious! 😭

Here are two I’ve tested recently that are worth a closer look.

v0 by Vercel

v0 is an AI UI generator by Vercel that turns plain text prompts into working interfaces. It works well alongside frameworks like Next.js, TailwindCSS, and shadcn/ui, which I selected as the tech stack for my project.

I’d been hearing about v0’s capabilities in creating user interfaces, so I was glad for a chance to take it for a spin. I used it to design and create the UI for Pooped Puppies, a puppy training school website.

To set the project up for success, I wrote a thorough project document. One thing I’m finding when working with AI agents: the more detailed your instructions, the better the outcome - much like managing a junior developer or onboarding someone to a large codebase.

Based on my specs, v0 generated the UI components and page structures. The design came out clean and polished, and when I asked for changes, it was quick and easy to refine them inside the v0 environment. Once the UI was dialed in, I exported the project and downloaded the codebase to continue development in Cursor.

I was impressed with the code quality. The structure followed best practices, and the components were clean and well-formed. It gave me a solid starting point to add interactivity and backend integration without needing to reorganize or refactor. Overall, I’d rate v0 very highly for UI prototyping and plan to continue using it as a go-to tool when kicking off new web projects.

Replit

Replit is an all-in-one browser-based development environment that has embraced agentic coding with its own built-in AI tools. It’s designed to help anyone - from beginners to pros - spin up and deploy projects with minimal setup.

Replit was one of the first platforms to embrace "AI coding agents," and I had a chance to use it in a real-world scenario when a friend sent me the first of what I expect will become a common message:

“I created this app using AI, but now it’s broken and the agent can’t seem to fix it. Can you help me make it work?”

I wasn’t surprised. It wasn't too hard to predict that the rise of “vibe coding” would create a new kind of technical debt. 😁

I logged in, explored the app, and found the Replit IDE and chat interface to be pretty intuitive. Within a couple of hours, I had the app running again. But it wasn’t as simple as prompting my way through it - the AI agent had hit some blind spots and couldn't see the problem. It took some good old-fashioned human debugging to get things back on track.

Once the core issue was resolved, the AI agent was able to jump back in and assist with writing code and updating the app effectively.

What struck me most was that my friend, a designer by trade, had managed to build a pretty complex app that integrated APIs and live data - all without traditional coding knowledge. That’s powerful, and I’m excited to see this technology mature.

Conclusion

These tools are impressive for rapidly prototyping UI, spinning up MVPs, or automating repetitive dev tasks. Will they replace developers? Not even close. But they are going to replace much of the low-level grunt work - and developers who embrace them will move faster than those who don’t.

That said, these tools are not yet producing production-ready apps without oversight. The generated code can have security issues, scalability limitations, and hidden bugs. The key is using them as accelerators, not substitutes.

TL;DR

Strengths:

• Rapid prototyping and MVP creation
• Making app development accessible to non-coders
• Speeding up experienced developers
• Genuinely fun - prompting up a working app is still a thrill

Weaknesses:

• Can stumble hard on complex projects
• Easy for beginners to get overconfident
• Generated code can have security and reliability gaps
• Unreviewed code can become technical debt fast

Since then, I’ve been deep in a much larger, older codebase at Quiltster - a project that’s been around for years - and trying to integrate Cursor into that workflow has been a different kind of challenge.

The good news? Cursor is still an enormous time booster, even in legacy code. It especially shines in areas where there’s a lot of repetitive structure or complexity to track - for example, building Bootstrap-based UIs. It handles class names, nested elements, and verbose markup like a pro. It doesn’t get tired, it doesn’t forget, and it never complains about indentation. 😉

What’s changed, though, is that using Cursor in legacy code takes a little more discipline. In Agent Mode, it can be overzealous - touching files it shouldn’t, or making assumptions that don’t apply to your project. That’s where rules come in.

Using Cursor Effectively in Legacy Projects

Here are some of the techniques I’ve found helpful when adapting Cursor to an older, complex codebase:

Project & User Rules

Cursor’s Rules system has evolved. What used to be a simple .cursorrules file is now a powerful set of .mdc files inside .cursor/rules/. These can be scoped globally, per-project, or per-file.

Use the “New Cursor Rule” command in the IDE or manage them in Settings > Rules. For legacy code, I recommend breaking your rules into focused, reusable chunks:

.cursor/
  rules/
    code-style-and-conventions.mdc
    error-handling.mdc
    auth-logic.mdc

Global “User Rules” can also be helpful for coaching the agent to stay out of the wrong files or directories entirely.

Project Documentation

Since Cursor doesn’t yet sync rules across teammates, I’ve started keeping documentation files in a documents/ folder at the root of the project - which Cursor can read and reference in-context:

documents/
  changelog.mdc
  core-features.mdc
  system-architecture.mdc
  features-to-build.mdc

Pro tip: that features-to-build.mdc file can double as a to-do list - and you can have Cursor update it as it finishes features.

Ask Mode vs Agent Mode

If you’re seeing Cursor overstep, switch from Agent Mode to Ask Mode. Ask Mode is slower but more deliberate - it explains its thinking and usually avoids making surprise edits. You can toggle this in the bottom-right panel, and also choose which LLM to use.

Cursor continues to improve at a rapid pace. Even in the short time since Part 1, the IDE has shipped new features, cleaner UX, and better performance. The team seems to be on a tear - and hiring great talent - so I’m excited to see what’s next.

In the meantime, it’s totally possible to make Cursor a reliable pair-programmer even in older codebases… you just have to teach it the rules.

Cursor has this cool feature called Composer (⌘-i). It's an AI chat in a palette that can access your entire project. It can write changes across multiple files, suggest code, and even present you with diffs to accept or reject. When it’s working well, it feels like pair programming with a really fast (but not always perfect) dev buddy.

Rebuilding My Blog Site with Cursor

To put Cursor to the test, I decided to rebuild this very blog. It was a Django-based site I originally created back in 2011. It worked, but needed a glow-up. So, over one long weekend, I rebuilt it using Typescript, Next.js, and Composer. And let me tell you, Composer made things fly. I was honestly shocked at how quickly everything came together.

I started by setting up a Next.js Typescript project, using Prisma ORM, Tailwind CSS, and shadcn-ui for the components based on a recommendation from Twitter.

I wanted to migrate my database from MySQL to Postgres, and use Prisma instead of Django, so I had some manual work to do first. I exported my original database as JSON, and wrote a seed script for Prisma that imported everything. Then I set up a cloud psql database and imported all the data; using Prisma Studio I had a nice little admin to preview things.

Then, I switched into product manager mode and started describing features to Composer as if I were writing a Jira ticket. For example:

Create a header with a logo and home link on the left. On desktop, show nav links on the right for Blog and About. On mobile, replace the nav with a hamburger menu that opens a flyout. If you need inspiration, check out this site: [link].

Composer whipped up the basic structure in seconds. From there, I refined the design with a few more prompts. I spent some extra time adding custom animations, like bouncing balls in the header (because why not?) and a dark/light mode switch in the footer—both entirely created with natural language commands.

How This Accelerates Development

The real game-changer? Composer’s ability to remember everything, from documentation to style guides. It’s like having an instant recall of all the details you’d normally have to dig through Stack Overflow for.

Take Tailwind CSS, for example. Composer knows every single class and can apply them with precision. No more googling to remember the exact utility class—you just describe what you want, and it gets to work. Same goes for Typescript. Type safety becomes a breeze when your AI partner never forgets what types you’re working with. In fact, the little things that create overhead when developing new products with Typescript start to disappear, because Cursor doesn’t forget those details as it goes along.

Composer in Action

Here’s how to get the most out of Composer:

1. Prompt it with details. You can reference files, repos, or docs to give it context.
2. Let it do its thing. Review the changes. If it looks good, hit “Save All.” Test it out and refine if needed. If it totally misses the mark, hit “Reject All” and try again.
3. Check the diffs. Once you’re happy, click “Accept All” to finalize the changes.

Where Composer Saved Me Big Time

• Search functions for the blog and admin.
• Sidebar components like “Recent Posts” and “Popular Posts.”
• Paginated blog posts.
• Generating an RSS feed.
• Loading skeletons (which Composer did better than I could).
• Password-protected admin system, with login and reset password flows.
• Admin pages for creating and editing posts, complete with an S3 image uploader and live Markdown preview.

Normally, these features would take a decent chunk of time. Composer? Knocked them out in minutes. It was like magic—just typing out what I wanted, and boom, done.

Areas Where Composer Fumbled

Of course, it’s not all rainbows. Composer had a few hiccups:

1. Forgetting the site theme. I had to remind it about dark/light mode constantly.
2. Reinventing the wheel. Sometimes it would write new code instead of using existing components.
3. Sticky sidebar trouble. Implementing the sticky sidebars resulted in several failed attempts, and I had to step in manually. I don't think the LLM can "see" something like a scrolling effect in action.
4. Unwanted changes. Occasionally, it would mess up things that were working fine in previous iterations. Keep an eye on the diffs!

These issues feel like growing pains, and I’m optimistic they’ll get ironed out with time.

What’s Next?

My next big project with Cursor will be re-writing the seller portal for my startup, Quiltster. It’s been on my to-do list forever, but with Composer as my pair programmer, I think it’s finally time to tackle it. Stay tuned—I’ll be documenting that journey too!

Let me know what you think!

The New Look and Feel

Fast forward to today, and I’ve decided to give the site a complete overhaul. This time around, I’ve used TypeScript, Next.js, and Prisma ORM—some of the best frameworks available right now. These tools are the best of the best TODAY, and have made building the site both a breeze and a joy. Honestly, the difference is night and day. Not only does the site load faster and perform better, but the developer experience is so much smoother.

A Little Help From My AI Friends

Here's the twist: I didn’t do it all by myself. I had some AI assistance along the way. Enter Claude 3.5 (Sonnet), a popular language model, and Cursor for my IDE. Working with these tools has been a game-changer. I managed to build the entire site, including a custom admin interface to manage blog posts and categories, in just a few days! That's right, days—not weeks, not months. The productivity boost I got from having AI assistance was incredible.

One of the more fun parts of this rebuild was experimenting with the header. In Cursor’s Composer view, I played around with natural language to create something unique, something just for fun. It felt less like coding and more like having a conversation about what I wanted to build.

Looking Forward

I’m genuinely excited about this new way of working. I believe that AI-assisted development is going to transform the industry. As I continue to explore this space, I plan to write more about how AI will impact software development, and how engineering departments will need to adapt their training, processes, and policies to stay ahead of the curve.

For now, the experiment of rebuilding my website using Cursor and TypeScript has been a huge success. I’ve got a shiny new site, a better platform to share my writing, and I’ve learned a ton along the way.

If you're curious about the tools I used or want to learn more about the process, feel free to reach out or drop a comment below. The future is looking bright, and I can't wait to see where this journey takes me!

Happy coding!

I've become convinced that we need to decentralize our social media and stop giving our data and privacy to "big tech" interests who package and sell it as they wish.

I also want to start contributing to the development of a real-world, decentralized, encrypted protocol to allow us a path forward.

I plan to write about that process here, and possibly use this blog or website to "dogfood" the concept. There are other people working on similar ideas, and I intend to start researching the best way to proceed. Let me know in the comments if you have any recommended reading or Twitter follows to pursue on this topic!

In the process of dusting off, I looked back at this website. I designed and built this site in 2011, and haven't touched it much since. Websites and web development have changed a lot since then, but the site still holds up pretty well.

I removed some items from my social sidebar, due to evolution:

• Facebook: Of all the social media services, FB is the one that disappoints me the most. They never bothered to get their privacy and security ducks in a row before going "big league", and have shown little accountability or responsibility for correcting this situation.
• Instagram: I just don't use it. It bothers me to know that it's owned by Facebook and all the data goes to the same place.
• Google+: Once "required" by the "fair" Google SEO algorithm for optimal placement, this service no longer even exists.
• YouTube: Similar to Instagram, I just don't use it and don't care for their data practices OR effect on toxic culture.

This leaves me with Twitter, LinkedIn and Github. Eventually I would like to see Twitter replaced with (or integrating) a decentralized service. Eventually I would love to never look at LinkedIn again, but I do use it professionally for recruiting, so I don't see that happening soon. And Github is far enough removed from my personal/social data that I view it as something not-quite-social-networky. More of a professional service as far as I'm concerned.

Older services I've removed in the past that I can see in my git history: Myspace, Foursquare, Flickr, Delicious, AngelList, Last.fm. Go back even further and you'll find MyBlogLog, Pownce, Plurk, and any number of social sites that in the past were consumed by the big players.

R.I.P., social media of the past.

It bothers me that once we move on from these services, our data disappears with them. Another great reason for decentralizing our social media - anything I publish here is mine to keep, delete or republish whenever I want. A protocol allowing me to publish and control my own content regardless of where it is owned/hosted would solve that problem.

I'm excited about this upcoming effort. It's bigger than apps, bigger than #hashtags, and presents an opportunity to correct some of the mistakes made in implementing our digital social lives.

The last version of this site had a gorgeous custom threaded comments section. I had not included that with the package yet because I really wanted to overhaul it. As nice as it was, it was very prone to comment spam (nasty!). I had ended up turning off comments on nearly every post in my blog as a result.

I upgraded the blogs to Django 1.7 recently and noticed that Django's comments had been deprecated, so I was going to need to dive in even deeper to rebuild the comments. At that point I thought "why would I be doing this?" and went to check out Disqus. They have a very nice commenting plugin that works great, is free, and solves the spam problem. Boom!

I had to choke down a bit of NIH, but really - why work to maintain the software and keep spammers out when it's already available for free?

So in version 2.0.2 of the cp-blog software, integrating Disqus comments is as simple as adding a DISQUS_SHORTNAME to your settings.py, and you're off to the commenting races. Enjoy.

Anyone out there prefer another commenting system that I should integrate? Does anyone use Facebook comments anymore? If there's something you would like to see included, just leave a (Disqus) comment below.

I’m also very happy to be working with a company owned and run by developers. It’s a breath of fresh air to be sure. Working with a group that understands digital products and modern workflows, as well as trends in technology and consumer behavior, will be a lot of fun and I see a very prolific time ahead for me.

2014 has been an action-packed year already. Now that I’m joining such a capable group who really “gets it” and is constantly pushing the envelope of entertainment experiences, I can’t wait to see what the next year will bring!