Luckily, for me, Jay and I met and started a business. He happens to love setting up networks, managing servers, and making sure everything is online. Because of this, at Server Side Up, we end up hosting most of the applications that run our company ourselves. This gives us full control over our data, privacy, and at the end of the day, saves a ton on SaaS subscriptions. I can then focus on my specialty of app development and Jay can make sure our app stay online.

However, as time has gone on, we've become more and more passionate about self-hosting. Privacy concerns, security, unexpected price increases all contribute to our desire to run as much of our infrastructure as possible. It feels good and makes business sense to do it this way. Because of all the attention we've put into self-hosting our own applications, my interest has come full circle back to self-hosting personal apps as well, which has invoked a lot of interesting feelings about how I approach using software.

My Synology Server

Like I mentioned, I'm not a network admin. I needed something easy, so I got a small Synology that Jay set me up with. In the past, I've set up file servers with FreeNAS and other solutions. They were awesome, but I'd always run into something that I couldn't fix. With Synology, you plug it in and turn it on (the more complicated stuff Jay set up). For me this is a perfect entry point. I now have a running file server but also a small machine that can run Docker containers.

I didn't appreciate the fact that I can run a Docker container on my Synology for awhile. It wasn't until Jay helped me set up a Docker container on my Synology that I was like "holy smokes, I can actually do this". Granted, he had my static IP configured and a few other network rules. The first app I set up myself was Readeck, a simple article saver that can save from a browser extension or a link, extract the content, create a beautiful, streamlined way to read on any device. It's amazing. This app was the inspiration for why I'm writing this article since it has really set the tone for how I view software, data and long term vision.

The Feel of Owning Your Data

In the past, I've used other web bookmark tools. Pocket, Reader, etc. But none of them ever really set a tone. Pocket doesn't exist anymore, Reader was beautiful, but just didn't feel right. Honestly, Reader probably has more features than Readeck. However, when I set up Readeck, I felt something different. What I knew was that no matter what, I owned the data. Anything I saved would be there, on my machine for as long as I wanted. Readeck could change or shut down, but as long as it was running on my machine, I owned the data.

This is where my usage of the app really started to change. I started to think long term. I spent more time tagging and organizing my content. Even though there were less features than Reader, I invested more effort into using Readeck. I have my phone set up, my browser extension set up, everything funneling back into one centralized location where I had control of the content. And I have to say, that feeling was amazing. I was hooked.

Future Thoughts

Since I first installed Readeck, I've installed a few other personal apps. All with the same excitement and attention to detail as I took with installing Readeck. Even further, I've even built my own app for managing family recipes and installed on my Synology. This power to design software that solves your specific need and put you in control of the data and hosting is incredible.

Where I see the future going is not only will self-hosted applications be good for business and enterprise, but also for personal use. Both use cases are why we built our SaaS, Self Host Pro in the first place (and yes, you could self-host Self Host Pro if you wanted to). Self Host Pro allows users to design and build their own applications and sell them with the idea of being hosted by the customer on their own infrastructure. Jay wrote a simple script for people like me where you just need to spin up a server instance, paste the script and if you have a valid license, the app installs.

With security vulnerabilities running rampant ini the age of AI, no control over the infrastructure and your data being sniffed and sold without your permission, I believe the future is bright for self-hosters. No privacy invasions, you own the data, it's around for the long term. This makes sense for both personal and business applications.

Initial Thoughts on AI

AI is the best co-worker and assistant, biggest source of bugs, most amazing tool, and feared technology all at the same time. One day I'm blown away by how helpful AI is when attacking a problem. Instantly followed by holy smokes, what's the upper limit with this thing and how will it affect my career? The next day, it writes 100 lines to compare two strings. It really throws me for a loop.

Overall, I find it more handy than anything. But I believe that's because I already could make the app by hand, without the use of AI. I've been developing software for 20 years and having that experience is essential. Multiple times when I've pushed it to the limits, there are architecture issues, security vulnerabilities, and user experiences that were very WTF. However, when utilized correctly, it's extremely powerful.

Vibe Coding is a Lie

Well, maybe that's a little harsh. Vibe coding the "one-shot" million dollar app without any experience is a lie. It's fake dopamine. The "one-shot" app "works", but good luck. Successful apps built with AI all come from developers who know what they are looking at. To just keep prompting an AI to build what you want and have no idea what the underlying code is just sets you up for failure. Whether that's security vulnerabilities, user experiences that just make no sense, or code that's absolutely un-maintainable. You can make it work, but making it work for more than just yourself is a whole different ball game.

What I do like about "vibe-coding" is it helps new developers see what is possible. It sparks the creativity without the frustration. If you are learning to code and you pair with AI to explain the code while also building an app yourself, then I think vibe-coding is extremely powerful. However, once you know how to build an application, working with agents as a co-worker is where you can se some serious return.

Using Agents

Now, if you already know how to build an app, and you hand off work to the AI, you've become a team of 1 with the power of 50. Having previous knowledge of app development and knowing how systems are structured (more on this next), will give you so many advantages. You will design better prompts, you can scaffold the app (or at least guide the AI to) where the AI can fill in pieces, you will know what is right and what is wrong. And finally, you can do this at an incredible pace. The way I approach agentic workflows is as follows.

1. Scaffold your app

If you are using a framework, well then you have a huge head start. But no matter what, get your app scaffolded first. Install the packages you wish to use. Set up your authentication. Lay the bricks. Without the basics in place, the agent will gladly put what it thinks is best in there for you.

You can have the agent help scaffold the app and it actually does a decent job, just make sure you don't start off on the wrong foot. The more you can rely on your experience by using vetted packages or libraries, designing what type of system you plan on building, and how your application should function, the better prompts you will be able to give to the AI to add features to your app. And most importantly, do it the right way.

2. Build Context

Along with scaffolding your app, provide context. This could be through an MCP server, a CLAUDE.md file, agent rules, etc. The more context you provide, the better the outcome. Be wary of using third party MCP servers though. You think debugging your own solutions is hard, try debugging AI generated solutions that get context from an MCP server that goes against the grain. I try to limit the MCP servers I use and really scope them down.

For example, I do a lot of Laravel development. The framework has heavily embraced AI in an absolutely incredible way with their first party package, Laravel Boost. Laravel Boost provides context for all first party packages and framework structure. This is an essential MCP server for Laravel development. However, my approach, is not to install another Laravel specific MCP server that would provide conflicting information. Laravel Boost should be isolated in it's context to providing specific Laravel knowledge.

The context I do provide is iterative. As I add features, grow the product, make architecture changes, I update the context. I also refer from my context to reference MCP servers that provide more detail and up-to-date data. There's a fine balance of providing too much context and just enough to be fast and efficient.

3. Correlate Prompt Size + Complexity with Scope of Work

This has been my absolute go-to rule of thumb. The greater the complexity that I want accomplished, the larger and more detailed the prompt, and the smaller chunks I bite off at once.

So what does that mean? Well, if you are installing packages that are pretty standard, or building out small, common, beginning level features, you can probably do a small little prompt and accomplish a decent amount of work with pretty good success.

However, if you are doing business specific logic, with lots of steps and procedures that are unique to your app, the AI will need a hell of a lot more guidance. And you will need to do a hell of a lot more review. This is where developer experience is essential. AI can help, but it will only help with the quality of instruction and knowledge you give it. If you know how a feature or implementation should work and what tools to use, the AI will yield better results.

With these app specific logic implementations, my prompts are massive. The scope of work is tiny. It may be just a few functions, or an individual helper class. It's at these points where I tend to do most of the work myself and use AI to bounce off ideas or discuss different approaches.

4. Allow for Questions

The most helpful sentence to put after any prompt: "Please ask clarifying questions before you begin.". That one sentence makes all the difference. In my experience I feel that if I don't tell the AI to ask questions, it will confidently implement a feature that's not even close to what I want.

When I do instruct the AI to ask questions, the questions it asks help educate me on the full scope of what I'm looking for and the outcome is better, then expected. What do I mean by this? It gives the AI the freedom to clarify what it doesn't understand, but that could also prompt me to understand and think through what I'm trying to implement even better. It's literally night and day difference.

5. GIT. GIT. GIT

Finally, never trust 100% of the output and use GIT religiously. Before every prompt I make sure I have a clean worktree. Sure, modern IDE's like Cursor show the changes that AI makes, but if you are iterating on a feature, I highly suggest using GIT and all the power it provides. I mean, GIT has been around forever, it's so powerful and so easy to use, you can quickly see what the AI changed, revert pieces, and keep iterating as fast as possible.

I also think this goes without saying, never AI code directly in a production environment. This is an extremely dangerous development practice. AI can pull in malicious, poorly tested packages if you aren't careful, or build you a nice security hole. Always review the code 100% and make small, incremental commits that are easy to roll back.

Architecture Matters More Than Ever

If there's anything I've learned working with AI is you are the architect of the application and architecture matters more then ever. Knowing how to build and scale an app is essential. You can then guide the AI as a co-worker and a companion using pre-existing knowledge learned through experience. If you don't have that existing knowledge, sure you can make something, but if it grows beyond you, or you need someone else to maintain it, you are in for a challenge. That doesn't mean don't try. Actually the opposite, try even more. Just learn the development practices along the way.

AI is great at implementing the busy work, the validations, the tests, the small formatters and even some pieces of larger features. However, you need to tell it where these features should live and how it should continue to grow the application. Is your application modular? Even Driven? API Driven? Where do your objects live and are you following a MVC or Repository pattern? All these choices are up to you and should be followed throughout every feature. I also recommend thoroughly documenting where everything lives within your context. You are now an experienced product manager and senior level engineer guiding an entire team. Whatever information you think the team needs regarding architecture should be explained in the context.

Wrapping up

As your app grows, the knowledge of architecture and when to bring in other services becomes more and more important. Your previous knowledge of security, user experience, and code clarity is highlighted in the age of AI. While the models keep getting better and better, the job of the developer keeps evolving. However, without previous knowledge and confidence to build an app by yourself, you will have less of the vocab, descriptive terms, and understanding that is necessary to design prompts to make the AI accomplish what you need it to. Prompt engineering is real, but it's rooted in experience and understanding.

I'd absolutely love to hear your thoughts on this. I think, as developers, it's extremely important to share perspective. Especially in the age of AI. Feel free to reach out on X (Twitter) or LinkedIn.

While my profession is being a software developer, I have a ton of other hobbies and interests. I absolutely love creating, building and merging these hobbies together. For me, the biggest dopamine is taking a long task, a huge problem, and finding a more efficient, creative way to solve it. However, most of these problems don't fit a small form post dictated by an algorithm. They involve a lot of thought, planning, and communication. What I want to write about are these problems and cool ways of solving them.

I also want to share tidbits I find interesting, thoughts that I have, and apps/projects that I'm working on. Not just to talk into the wind, but to connect with other creative people. If we share different view points, great! Let's discuss them. I think civil discourse provides a better outcome and better growth opportunity than an echo chamber. If we have the same perspective, awesome. Let's connect and share ideas too.

One piece I really want to hit home is you can expect all thoughts on this blog to be my own, not written by AI. I want to make that clear. Everything on this blog is hand typed the old-fashioned way by myself. While I use AI as a super helpful research companion, ask it questions, bounce ideas back and forth, and brainstorm, I believe that communication from human-to-human should be done by, well, a human. Even if it's not perfectly structured, thoughts kind of scattered, it's human and that's what we need.

I really hope to spark some conversations and have a great time connecting. I'm excited for where this journey might lead! Feel free to reach out via email or the social links below and subscribe if you want new posts right in your inbox!