<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator><link href="https://www.andreaswagner.io/notes.xml" rel="self" type="application/atom+xml" /><link href="https://www.andreaswagner.io/" rel="alternate" type="text/html" /><updated>2026-05-28T15:00:58+00:00</updated><id>https://www.andreaswagner.io/notes.xml</id><title type="html">Andreas Wagner | Notes</title><subtitle>Independent Rails consulting, container hosting, and managed WordPress — run by one person in Tallinn. Whyservices, WellHost, WellPress.</subtitle><author><name>Andreas Wagner</name><email>site@andreaswagner.io</email></author><entry xml:lang="en"><title type="html">Taking on ownership of an aging and waning Rails code base</title><link href="https://www.andreaswagner.io/en/notes/2026-05-08-taking-on-ownership-of-an-aging-and-waning-Rails-code-base" rel="alternate" type="text/html" title="Taking on ownership of an aging and waning Rails code base" /><published>2026-05-28T00:00:00+00:00</published><updated>2026-05-28T00:00:00+00:00</updated><id>https://www.andreaswagner.io/en/notes/taking-on-ownership-of-an-aging-and-waning-Rails-code-base</id><content type="html" xml:base="https://www.andreaswagner.io/en/notes/2026-05-08-taking-on-ownership-of-an-aging-and-waning-Rails-code-base"><![CDATA[<p>The client came to me after a long journey with different agencies selling them spot time for partial developments and hotfixes.
When I took ownership of the codebase, the latest commits had been upgrading the Rails gems and making them work ad hoc. The application had no functioning test suite, so the upgrade was risky. The main outcome was that Rails idioms and styles had not been updated alongside the gem versions.</p>

<p>Mapping out the codebase was the bulk of the work; the actual upgrade is then only grunt work. The conversation with the client is the most important part. They had been living with the codebase for 14 years, and relying on their real-world experience rather than only the technical reality of the programme was key. Being able to understand and relate to what they focus on is the real work.</p>

<p>The result of the initial conversation, reviewing the codebase, and the infrastructure around the running app was the first deliverable. A report with</p>

<ul>
  <li>a high-level comment about the app’s repository,</li>
  <li>a list of all infrastructure dependencies,</li>
  <li>a summary of the current open issues, commit message history and branches, and codebase TODO comments,</li>
  <li>headlines and excerpts of six roadmaps for the way forward,</li>
  <li>further findings on public media about the history of the app and the code, the business history</li>
</ul>

<p>Halfway through I realised that the application code and the organisation around it had pivoted from a portfolio to a competition platform. The break is clear in hindsight, but I could also see in the git history how it had not fully manifested in the development process and feature prioritisation. The biggest debt was the remains of features that were either unused or irrelevant to the business, yet created dependencies and lingering complexity. The code only told the result, not the path to that situation.</p>

<p>After upgrading to Rails 8.1, the next step was to map out syntax updates and standardisation. Standardrb and Herb (HTML+ERB lint) helped with linting and controlling the views. Honeybadger helped point me to the most common errors and the most important parts to test.</p>

<p>I found a lot of code paths and features in the app that the client was not even aware of. The biggest help in clearing the path forward and removing the anxiety of touching the core business logic was cutting unused features (Facebook like/share, a privacy feature, dynamic navbar, participants view, name locking) and dead code.</p>]]></content><author><name>Andreas Wagner</name><email>site@andreaswagner.io</email></author><category term="maintenance" /><summary type="html"><![CDATA[This is part of a series of articles summarizing my last client work]]></summary></entry><entry xml:lang="en"><title type="html">Managing Multiple Freelance Projects Without Burning Out</title><link href="https://www.andreaswagner.io/en/notes/2026-05-21-managing-multiple-freelance-projects-without-burning-out" rel="alternate" type="text/html" title="Managing Multiple Freelance Projects Without Burning Out" /><published>2026-05-21T00:00:00+00:00</published><updated>2026-05-21T00:00:00+00:00</updated><id>https://www.andreaswagner.io/en/notes/managing-multiple-freelance-projects-without-burning-out</id><content type="html" xml:base="https://www.andreaswagner.io/en/notes/2026-05-21-managing-multiple-freelance-projects-without-burning-out"><![CDATA[<p>From my perspective, handling multiple freelance projects in parallel comes down to three things: organization, finances, and experience.</p>

<p>Financially, I started by roughly calculating how many hours I could realistically sell and how much income I actually needed. Once you know those numbers, you get a decent sense of what you need to charge. One big advantage of acquiring new clients continuously is that you can raise your rates by 10% each time and slowly test your market price. That’s much harder to do with long-term existing clients.</p>

<p>Organizationally, I think it helps to apply something close to franchise methods: abstract and formalize your workflows so they can be reused across multiple clients without your mental overhead growing exponentially. Consistent communication channels, repeatable work processes, formal structures — that kind of thing. It also makes context switching much easier.</p>

<p>Splitting work into clearly defined blocks can help as well. For example, you might dedicate one week to each client and reserve one day for planning and communication with the others, depending on what time units make sense for your work.</p>

<p>The knowledge and experience side depends heavily on your specialization. If you already operate in a narrow niche, it matters less because your projects will naturally look similar.</p>

<p>Right now, I focus almost exclusively on Ruby on Rails. The jump between Rails development and system administration is fairly large, so I’m trying to stay concentrated on Rails projects and deepen my experience there. My hosting clients are mostly running in maintenance mode. A larger infrastructure migration or automation project in an unfamiliar environment would require full focus again, and that would be a pretty hard context switch away from the Rails work.</p>

<p>Of course, all of this is still somewhat theoretical until you actually have a selection of clients to choose from. That’s the real bottleneck.</p>

<p>I currently have a handful of hosting clients, but they don’t generate much revenue. So far, I’ve mainly worked on one larger Rails project, and now I’m trying to use references and personal contacts to find more work. At that point, the key question becomes your profile: how you position yourself in the market and how you market yourself effectively.</p>

<p>When it comes to client acquisition, different target groups require different narratives. Enterprises, mid-sized companies, startups — they all have different expectations and priorities. So the approach depends heavily on the specific people you want to work with. That’s essentially where the real marketing work begins.</p>]]></content><author><name>Andreas Wagner</name><email>site@andreaswagner.io</email></author><category term="business" /><summary type="html"><![CDATA[How]]></summary></entry></feed>