Customer obsession is a powerful value—but when taken too far, it can lead to burnout, reactive teams, and a fragmented product. This post explores how to apply it with balance, strategy, and respect for your team.
Technical debt isn’t just messy code — it’s a trade-off. In this post, I break down what tech debt really is, the different types teams encounter, and when it’s actually smart to incur it. From MVP shortcuts to regulatory deadlines, I share real-world examples, a decision-making framework, and tips for making debt visible and manageable — without slowing your team down.
At Buoy Software, I led the design and development of our first Software as a Medical Device (SaMD), which was my first experience operating within an FDA-regulated environment. It was a great learning experience, but it came with a lot of heavy documentation. One of the most time-consuming parts was compiling the Design History File (DHF) — the set of artifacts that describe how the system was built and tested. A central piece of that file is the Software Design Specification (SDS), which describes the behavior, design, and rationale for each component in the system.
Over the years 3D printing has become more and more common. I’ve casually followed along thinking it was something that seemed fairly interesting but something out of my reach whether it be due to pricing or lack of ability to have anything useful to print. However recently for my 39th birthday I received a Bambu Labs P1S with the AMS and I can’t believe what I’ve been missing out on for the last few years. Here’s what I’ve learned.
This post was originally posted on the Buoy Software blog.
In the ever-evolving world of web development, choosing the right technology stack is crucial for building efficient and maintainable applications. We moved away from React and GraphQL, opting instead for traditional REST APIs and Rails-based views, leveraging the power of the ViewComponents gem.
Buoy Software’s journey began with a mobile application built using React Native and powered by a GraphQL API in a Ruby on Rails application. The success of this project led us to adopt similar technologies for our web application, resulting in a React based front-end using webpacker. This approach allowed for code reuse and consistency across platforms, which seemed like an ideal solution at the time. For our small team, it was easier to maintain a shared pattern when moving between the React Native application and our web application.
This post was originally published on the thoughtbot blog.
You’re excited about building a new application which allows users to sign up and host their own blog. You decide that each blog will have their own space by providing a subdomain.
Let’s start off with a feature spec.
require "rails_helper"
feature "user views a blog" do
scenario "homepage" do
blog = create(
:blog,
subdomain: "bobloblaw",
title: "Bob Loblaw's Law Blog",
description: "Welcome to my new blog.",
)
visit root_path
expect(page).to have_content blog.title
expect(page).to have_content blog.description
end
end
In our app we render the blog homepage using the following:
I’ve recently started learning iOS and Swift and I wanted to share my experiences so far.
This post was originally published on the thoughtbot blog.
The Rails fresh_when method is a powerful tool for conditionally caching resources via HTTP. However there are some pitfalls. For one, fresh_when only supports the default render flow in a controller; if a client’s cache is not fresh, it will just render the related view. We cannot utilize things like render json:.
Fortunately, Rails provides us with more tools to work with HTTP conditional caching. Some of the basics behind HTTP conditional caching are assumed in this post. If you haven’t already, or you just need a refresher take a look at Introduction to Conditional HTTP Caching with Rails.
This post was originally published on the thoughtbot blog.
HTTP provides developers with a powerful set of tools to cache responses. Often times we don’t want a client to blindly cache content that it has been given. We may not be able to rely on setting specific expiration headers either. Instead we need a way for the client to ask the server whether or not a resource has been updated.
HTTP provides us with the ability to do this with conditional caching. A client can make a request to the server and find out of the server has a new version of the resource available.
A guide on building high-scale JSON APIs in Rails using ActiveModel::Serializers, Key-Based Caching, and Rack::Cache. This post covers organizing APIs, leveraging HTTP caching, and ensuring high scalability.