As soon as I started using Cushion again as a full-time freelancer, I fell in love with it all over again. I also realized that it still holds up after all these years! As a returning user, however, I immediately noticed a few rough spots since I last freelanced. These are the kind of rough spots that I’d otherwise miss if I weren’t a user of my own app—and I did miss them. After reminding myself that I can actually fix the rough spots that I come across, I spent an evening smoothing them out.

The next day, I used Cushion as I normally would, but with the usual pain points no longer there. I felt an instant jolt of delight when an especially cumbersome flow in my daily routine was reduced to a single click. If I were a regular user, I would’ve never bothered to reach out to support to mention the extra clicks in this flow, but I’d still feel them chipping away at me. Rough spots like this could’ve worn me down enough that I might eventually fall out of love with the app. But because I work on Cushion—and now use it regularly—as soon as I feel a rough spot myself, I want to fix it immediately because I know other users feel it, too, …but not enough to report it. This prompted me to send a message to my users, giving them the chance to share any rough spots they experience in their day-to-day use of Cushion, but haven’t bothered to mention.

Unsurprisingly, I heard back from a handful of users with plenty of rough spots to keep me busy for a while. The biggest surprise, however, was the number of users who replied that they couldn’t think of any. (Some Cushion users are too nice to give it to me straight!) While I appreciate the kindness, I’m craving feedback right now. I spent the next few days recording all the rough spots into a to-do list. Now I have the low-hanging fruit I need to build some momentum as I get back in the saddle.

I’m not a “Let’s fucking go!” guy, but now would be the time to say it.

Reply via email

Collaboration in Cushion was like “teams for freelancers”, but there were no dedicated teams. Any user could invite any other user to a project. Or they could invite a non-Cushion user to a project solely to track their time, like a subcontractor. Then when it came time to create an invoice, they could include their own tracked time along with the subcontractors’. The original user would simply pay extra for “seats” for their collaborators, and that would be an extra $5 per seat per month or so. By inviting subcontractors to a project, this would potentially encourage more non-Cushion users to start using Cushion. This is that “network effect” I mentioned, combined with a way to get more monthly recurring revenue out of a user—especially since a handful of folks have begged for multiple users in the past.

On paper, it sounded like a great idea that makes complete sense. In the implementation, I think we went about it the wrong way both on the backend and on the frontend. Instead of taking the straightforward approach of introducing a separate parent “team” model that could have many users and be the owner of the shared projects, we decided to shoehorn the database associations for collaboration into the existing user model. With this approach, a user could have “members” (users) and “readable” and “editable” datasets for anything that’s shared. Then for anything created, like time tracking entries or workloads, the user ID for these would be the member, but model would also be tied to the parent user. This led to an entire layer of complexity added to almost every database query that involved these models. And that led to slower database queries for everyone in the app—not only folks using collaboration.

On the frontend, “collaboration” was its entirely own section with subsections for all the existing top-level sections—scheduling, time-tracking, etc. This essentially doubled the footprint of the app, but in a way that felt duplicated instead of built-in or well-thought-out. Again, if I had only followed the straight-forward approach of a team-like model where you could view different workspaces, ala Slack, it would be much more straightforward—especially if one of those workspaces is your own personal one.

In hindsight, the correct solution seems so simple, but I need to remember that six years of time and experience has accumulated since then. Of course, it seems simple now, but it didn’t then—especially in the stressful situation of needing a home run. I can’t knock myself for that, but on the glass-half-full perspective, at least I didn’t actually launch collaboration, get loads of folks to rely on it, then realize it wasn’t right for the app. And, if I ever wanted to revisit the concept with a more straightforward approach, I now have the wherewithal to do it in steps. First, I’d introduce the concept of workspaces for individual users, so they could have multiple businesses. Then, I could introduce the ability to invite other users to those workspaces. That would be the correct approach.

As much as I want to give it another shot, I first need to make Cushion perfect for the individual. Then I could reconsider collaboration. With this in mind, I’m determined to be much more consistent with user research going forward, so I could polish all the rough spots that nag folks on a regular basis. If you’re eager to share your thoughts, I’ve re-enabled chat in the app. Hit me up!

Reply via email

When I first started building the table, I knew I wanted to lean on markup as much as I could. I’m a purest at heart, so I prefer writing HTML when I need HTML and CSS when I need CSS. If you read the previous post, I’ve certainly had my fair share of “clever” approaches to rendering HTML, like concatenating strings, and I’m so over that phase of my engineering life. Luckily, Vue 3 is incredibly fast when it comes to rendering, so I don’t need to worry about performance the way I did with Angular back in the day. Now, I can just write the markup, wire up the data, and expect instant rendering.

Since I knew I’d be reusing this table throughout Cushion, I decided to make a “base” table that I could use across clients, projects, and invoices, but I wanted to make sure it was specific to “items”—not an entirely generic base table. I’ll explain. There’s bound to be areas where I need a table that doesn’t look like the tables for invoices, etc., and doesn’t use the kind of data that goes into an invoice table, so instead of making a <Table> component and calling it a day, I opted for an <ItemTable> that’s more intentional in its use and infers that this is a table for “items”. (I admit “item” is an incredibly ambiguous word here, but I strangely don’t like using the word “model”, which is what I’m referring to—a model with an ID.)

From here, I was able to build all the child components for an ItemTable, which include an <ItemTableCell> (or <td>), <ItemTableHeader> (or <th>), and <ItemTableRow> (or <tr>). These components are intentionally primitive because they’re meant to be extended. Within the components themselves, however, they’re styled to the design of the item table. They also handle all the aria-role attributes, so I can maintain accessibility while ejecting from the table-based display styles. With these low-level components, I can…

• extend the <ItemTable> to make an <InvoiceTable> that takes an array of invoices and renders them as invoice rows

• extend the <ItemTableRow> to make an <InvoiceTableRow> that takes an invoice and renders the relevant cells

• extend the <ItemTableCell> to make a collection of cells to handle any formatting needs, like currency, dates, durations, etc.

All of this combined lets me easily compose tables while compartmentalizing their logic and styling. I no longer need a long config object full of callbacks to determine everything, like in past attempts. I do still have an initial config, but it’s limited—in a good way—and makes much more sense now through the use of composables (or hooks in React).

The last time I rebuilt this table, in 2017, the concept of composables didn’t even exist. Now, I’m able to configure a table with a `useTable` composable that takes an array of columns (for config), an array of rows (for data), and an optional order (column name and direction), then returns reactive arrays for the filtered columns and sorted rows.

const { columns, rows } = useTable({
  columns: [
    {name: "Color", type:"Color", sortKey: (invoice) => invoice.client?.color || "#bbb"},
    {name: "Number", type:"String", sortKey: "number"},
    {name: "Client", type:"String", sortKey: (invoice) => invoice.client?.name || "(no client)"},
    {name: "Created", type:"Date", sortKey: "created_at"},
    {name: "Updated", type:"Date", sortKey: "updated_at"},
    {name: "Sent", type:"Date", sortKey: "sent_on"},
    {name: "Due", type:"Date", sortKey: "due_on"},
    {name: "Paid", type:"Date", sortKey: "paid_on"},
    {name: "Amount", type:"Currency", sortKey: "total"},
  ],
  rows: invoices,
  order: {column: "Amount", direction: "Desc"},
});

The config for the columns includes the column name as well as its type and sort key, which is either a key on the model or a callback to dig deeper. Callbacks are handy for specific cases where the sort key isn’t the raw property value. In Cushion’s case, sorting by color—which is a thing—requires that I convert the hex colors into HSL colors and sort by hue. As for “type”, I’m especially excited about this approach because it removes so much manual work. As an example, if a column is of type “date” or “currency”, the table knows to align those columns to the right and narrow their widths. Or, for a color-typed column, I could actually pass the raw hex color as the sort key, like above, and the column could know to automatically convert it to a hue before sorting.

const { columns, rows } = useTable({
  ...
  includedColumns: ["Color", "Number", "Client", "Amount"],
});

If anyone’s especially curious, you might be wondering why this composable would need the array of columns only to return them again. This is because it also takes an includedColumns property, which is an array of the column names to show. In Cushion, there are actually three invoice tables under the “Invoices” tab—“Drafts”, “Invoiced”, and “Paid”. All of these tables render invoice rows, but each of these tables show different columns that are relevant to the invoices’ status (e.g., a due date for the “Invoiced” table and a paid date for the “Paid table”).

const { columns, rows } = useTable({
  ...
  includedColumns: ["Color", "Number", "Client", ...props.includedColumns, "Amount"],
  order: props.order,
});

In the past, these were three separate tables, which meant a lot of copy/pasting and reusing code on a column-by-column basis. This time around, however, I’m actually thrilled with the idea of using a single <InvoiceTable> component that by default includes all of the possible columns that an invoice table could have. Then, I can specify which columns to show—solely by name—as well as which column to sort by. This makes the actual implementation of each invoice table incredibly simple because the code is only several lines of markup whereas before each table had its own file with a full config. Also, now that Vue supports generically typed props, composing these tables is much easier and type-safe because the table knows which columns and specific model it supports.

<InvoicesTable
  title="Paid"
  emptyMessage="No paid invoices"
  :invoices="paidInvoices"
  :includedColumns="['Sent', 'Paid']"
  :order="{column: 'Paid', direction: 'Desc' }"
/>

While I’m really happy about this approach, I admit I’ve only dealt with rendering so far, which is the first step, but it’s the easy one. Next up, I’ll need to dive into interactions, like context menus and drag-and-drop. I’m not worried about these, but I know full well that they’re pivotal decision moments. Can I still maintain a “pure” approach that’s clean, reusable, and intuitive? I think so! And that’s my goal.

Reply via email

Here’s the e2e.yml workflow file that you need to add to your project’s .github/workflows directory (assuming you’re using Node v20 and pnpm):

name: End-to-end testing
on:
  deployment_status:
jobs:
  e2e:
    if: github.event_name == 'deployment_status' && github.event.deployment_status.state == 'success'
    timeout-minutes: 60
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: actions/setup-node@v3
      with:
        node-version: 20.x
    - name: Install dependencies
      run: npm install -g pnpm && pnpm install
    - name: Install Playwright Browsers
      run: pnpm exec playwright install --with-deps
    - name: Run Playwright tests
      env:
        BASE_URL: ${{ github.event.deployment_status.environment_url }}
      run: pnpm exec playwright test

This should read pretty easily if you’re familiar with GitHub Actions, but it triggers upon a deployment status change and only runs Playwright if the deploy is successful.

In your Playwright config, point the use.baseURL property to your BASE_URL environment variable, which represents the generated URL for the preview deployment:

export default defineConfig({
  use: {
    baseURL: process.env.BASE_URL,
  },
});

Finally, push to GitHub. Assuming you have automatic deploys set up with Vercel and GitHub, you’ll see the results of your deploy in your pull request, then upon a successful deploy, the e2e workflow will start running—pointed at your preview deploy. It’s this easy. Don’t be like me and go down the outdated path of waiting for Vercel deploys or deploying from GitHub Actions. You don’t need that. And if you do, you don’t need this post.

Also, If Playwright seems to stall when running, it’s probably because you have Vercel Authentication enabled in your Deployment Protection settings. You’ll either want to pay Vercel $150/mo for Protection Bypass for Automation, or disable authentication. Unless you’re working on something super secret, disabling authentication is fine. And if it is super secret, you can afford $150/mo.

Hope this helps someone.

Reply via email

If I’m looking to build a working app sooner than later—and I’ve already proof-of-concept’d out the fun-yet-uncertain parts—then I can start with the boring-yet-essential parts. These tables are basically spreadsheets fed from the database. They ingest the data, display it, and add it all up in a way that’s useful for freelancers. At the end of the day, when a user is looking for a specific date, invoice amount, or payment status, they’re going to look at the tables first. Then, for a quick look at their progress over the year, they’ll check out the visualizations.

Believe it or not, I’ve actually built half a dozen versions of these tables for Cushion over the years, and what I’ve realized from revisiting the code is that my age and experience is directly correlated with my “cleverness”—or lack thereof. The younger I was when writing the code, the more roundabout my approach was. As I got older, my code became more straightforward. I’ve found that this applies to my code in general, but it was truly highlighted when revisiting the code for my tables.

The first table I built for Cushion was actually written with Vue.js, but it never made it to production because I switched to Angular shortly after. Vue.js was brand new at the time and not battle-tested enough for me to have confidence in it yet. As a funny aside, I know for a fact that the journal post about this table was written a long time ago because its images weren’t even retina yet!

The first table that made it to production is hilariously a single Angular file that takes a config object and renders the HTML by plus-equalling a string all the way down… Yeah, you heard right. I assume this was for performance reasons (because Angular), but it’s also complete madness. At the same time, the code is well-organized and pretty easy to grasp, but here’s the best way to put it: I wouldn’t want to see this code on the first day of my new job.

The next iteration of the table was a CoffeeScript class that gets extended and uses getter methods for everything. Again, too clever and requires a sherpa to find your way around the code, but at least I used templates this time (with lodash) instead of manually concatenating a string. I did notice, however, that I completely abandoned semantics with this version by ditching <table> tags in favor of living in <div> city for easier styling. Little did I know you can have the best of both worlds with semantic tags, easy styling, and proper accessibility, but I didn’t learn that until years later.

The most recent iteration of the table (albeit five years ago) uses Vue 2’s Options API and Mixins. This approach had a lot going for it because of Vue’s templating and reactivity, which was a huge leap forward because I no longer needed to manually re-render the HTML with every change. I still relied heavily on config objects, but they were now computed properties, so I also didn’t need to directly call getter methods like before—I simply looped through the data and referenced the properties.

My overall gripe with this version was the use of mixins. I never loved mixins in Vue because it’s never clear what a mixin is doing under the hood unless you dig through the code. This makes troubleshooting and searching for specific references really difficult—especially when a mixin creates props or reactive data. This is also why I’m head-over-heels for Vue’s composition API because, combined with composables (aka “hooks”), everything you need to reference is exposed, and it feels like writing straight vanilla JavaScript—nothing is buried and nothing feels “magical” (in the way that you can’t understand or troubleshoot it).

Ok, phew. This brings us to today. I’m building a table for the nth time, but the scenario is different:

• I have 10 more years of experience under my belt

• I now fully test the frontend, which helps to weed out “clever” code

• I’m committed to semantic HTML and accessibility, so the markup will be “proper”

• I’m using Vue 3 with the Composition API, which is the closest Vue’s syntax has gotten to clean ol’ vanilla JS

I haven’t finished building the table, so this post is somewhat premature, but there was plenty of “history” to share before writing about the latest iteration. That said, I’m making great progress already.

I mentioned before about using <table> tags with proper accessibility and flexible styling. Here’s what I meant. If we keep the <table> as display: table, styling is affected by the default table styles, which make certain styles impossible, like putting a bottom border on a <tr>. If, however, you set the table’s display to grid or flex, you can gain the styling flexibility, but you also lose accessibility—the table will no longer have its “table” role (in Safari, at least. It looks like other browsers no longer drop the role as of the time of this writing). Fortunately, it’s not difficult at all to reinstate accessibility roles for the table by simply setting the role attribute on each element. Every single table element has its own role value, and since I’m writing my own components for these elements, it couldn’t be easier to set these roles once and have them applied everywhere. I could actually write an entire post about this, but… it’s getting late, so I’m going to stop here.

While I do feel great so far about how I’m building this table component, I know I’m still in the easy stage—I have yet to implement any interactions, including sorting, drag & drop, or context menus, so there’s still plenty to work through. That said, I feel like I’m in the best position I’ve ever been in to write the most future-proof version of this table yet. And I know—it’s just a table. But when you’ve iterated on a single component over the course of a decade, recreating it every few years with the latest tech becomes a fun exercise, like building a to-do app with different frameworks. Or maybe I’m strange for thinking this is fun… It is fun, though, …right?

Reply via email

I still remember this ironic tweet of mine and how I fell right into this hole:

Now that I’m rethinking everything, I’m eager to go back to basics with a navigation that limits—or rather contains—the scope. The original tab-based navigation for Cushion actually fits the bill pretty well, as it’s confined to the max-width of the app, but it’s also influenced by the tab count. Three tabs look great. Four tabs is pushing it. Five tabs?—time for a long look in the mirror. That’s probably an extreme take, but this time around, I’m really aiming for laser focus.

For Cushion, if I want tabs for “Clients”, “Projects”, and “Invoices”, then a few admin tabs, like “Account”, “Preferences”, and “Billing”, I can simply put those in separate views, like I did with the original Cushion—one view for actually using the app and the other for admin. Clicking the user’s name in the header takes them to the admin view and swaps out the tabs for the admin tabs. Then clicking Cushion’s logo follows the standard of returning “home” to the main view of the app, where the feature-focused tabs are shown.

Going back to tab count for a moment, while I do think three is the sweet spot for feature-focused tabs, I actually don’t have a problem with a higher tab count for admin views. The user doesn’t spend nearly as much time there as they do in the actual app, so I’m not bothered by a few extra tabs for clarity—as long as the user can get to where they need to go in two clicks or fewer, I’m happy.

Since I’m looking to return to simpler times while also modernizing and improving Cushion along the way, one consideration I’m thinking about is personalization through color. The existing Cushion is pretty grey, but the original Cushion was very grey. That said, once the user starts filling up the graphs with client colors, the grey fades into the background as a canvas. In any case, I’m toying with the idea of introducing a personalized “theme” color that could be unique between users. Strangely, Cushion has always had a setting for the user’s favorite color, but I never ended up wiring that to anything. While I’m currently focused on the navigation, this might be a good time to tie the theme color to the UI.

By using the background of the top “header” area for the theme color, I could introduce personalization while still maintaining a neutral canvas for the graph below it. The tabs would then need to embrace black or white alpha colors instead of using a greyscale, and I’d need to add logic for determining whether to use black or white text to maintain strong contrast, but that’s easy enough. The real question would be whether I provide a preset color palette to ensure the UI looks good or allow custom colors. The answer to this might be the “why not both?” meme.

I’m off to a good start with this navigation already, and I feel good about its longevity. I am anticipating several edge cases, like clicking into an invoice and how to handle that with tabs, but I’m not worried—there are plenty of best practices to lead the way and I’m not looking to reinvent the wheel.

Reply via email

Personally, I’ve never had a problem thoroughly unit testing components, but when it comes to code that interacts with the API—where you should rely on end-to-end testing—I always feel the weight of the initial setup and tell myself I’ll do it later, but never do. With the existing Cushion, if I wanted to set up e2e testing at this point, I’d need to find a way to run all the servers within GitHub Actions, which is a daunting task (for me). Alternatively, I could do what plenty of folks probably do, which is to run their e2e tests against the staging server. Then, you just need to make sure you clean up after each run.

Since I’m starting from scratch—and determined to start on the right foot—I can keep e2e testing in mind from the get-go. Of course, I’ll also unit test components, but the coverage from e2e tests will be invaluable for sanity-checking the actual user flows. It’s far too easy for unit tests to pass while an unwritten e2e test would be failing—especially if you resort to unit testing API interactions with spies, but your API changes and your spies don’t. (I can hear a few of you nervously laughing right now…)

By using Supabase as my pseudo-backend that provides a direct client-side connection to the database, it’s much easier to set up e2e testing from the beginning (as long as their API is available). They do also have a self-hosted version if I wanted to go full neckbeard, but hosted will suffice for me.

As for the test harness, I’m using Playwright, which has emerged as the go-to option for e2e testing. There are others, like Cypress, but I feel like Playwright speaks more my language and would be familiar to anyone who has used Jest or Vitest. For those who haven’t written any e2e tests before, it’s actually fun. You simply write line-by-line what the user should do, like “go to this page”, “find this input”, “fill it in”, “click this button”. Obviously this is pseudocode, but the actual API reads just as easily. Playwright also has a codegen feature where you can record yourself clicking through the browser and it’ll write the test for you. Seriously, with features like this, you have no excuse.

So far, I’ve been able to fully test the auth flow as well as an initial setup form. These two cases have given me enough experience in this new stack to know how to quickly handle most situations. Along the way, I’m even writing helper functions, like one-line sign in, etc. The only hiccup I’ve come across is how best to reset the database, so I can do a clean run each time. I’m sure you can run a query on the database directly before or after the tests run, but instead, I saw this as an opportunity to implement a feature folks have asked for in the past—resetting an account.

For Cushion, users often become subscribers for a couple years, then they might take a full-time job and no longer need to freelance or use the app. Several years later, they might return, but want to start fresh with an empty account instead of returning to their old data. This is where a reset feature comes in handy.

I do realize that this is a dangerous feature and resetting your account is not something to take likely—especially for the users who have been with Cushion since the beginning. With those folks, we’re talking about almost 10 years of data. Because of this, resetting your account will certainly come with a safeguard in the form of a dramatic “Are you sure?” prompt that makes you type exactly what this feature does. I imagine I’ll eventually opt for a database query to clear the database to save time on click-throughs, but for now, this works and unblocks me.

Next up, I’ll start to dig into the actual app by setting up all the models as I need them, and make something usable. I’m excited!

Reply via email

The existing Cushion is hosted mostly on Heroku—a once-exciting platform that now seems stuck in 2010, when it was acquired by Salesforce. There’s still a lot to love about Heroku, but I’m looking elsewhere this time, in the direction of Vercel. This is a no-brainer for me and not much of a risk because I’ve been using Vercel for pretty much every website I’ve hosted over the past several years. The speed and ease in which you can go from repo to hosted website—with automatic deployments between dev, preview, and prod—is the way the web should be. That said, this will be my first time hosting an actual app with real users on Vercel—beyond a marketing site or a hosted form—so I can’t say I’ve had to troubleshoot something going wrong on Vercel. At the same time, I plan to greatly simplify the backend because it honestly doesn’t need much beyond what can be done in the database. And that’s a perfect segue into our next topic—the database.

Since the start, Cushion has used Postgres as its main database, and I have no regrets with that choice—I’ve always been a relational guy and Postgres only seems to get more and more feature-rich with each and every upgrade. The world around Postgres has gotten pretty interesting over the years, too, with database providers making the new Postgres features more turnkey. This is why I’ve landed on Supabase as my database provider. I have no problem coding a backend, but as soon as I saw that you can use a Postgres database directly from a static frontend and it handles authentication?—I was sold. On top of that, Supabase takes care of the hairiness of Postgres’s realtime features, so you can subscribe to messages, presence, and database changes with a simple client-side listener—sold again. These features unlock so much potential for a modern Cushion, and Supabase makes the features so easily accessible that I can casually experiment with a random idea before feeling like I need to commit.

Now that I’ve touched on the backend—or rather the lack of need for a traditional backend—let’s look at the frontend. Anyone who knows me knows my preference for Vue, so this is another no-brainer. Oddly enough, though, the majority of Cushion’s frontend actually isn’t Vue. When I first started working on Cushion back in 2014, Vue was only starting to make a name for itself. I gave it a shot for a few trips around the block, and while it was fun, exciting and new, Vue didn’t have the maturity I was looking for, so I friend-zoned it. I ended up playing it safe with Angular (v1.2), which shared some similarities with Vue at the time, but was also structured like the MVCS (model, view, controller, service) architectures I knew and loved in the AS3 days. While I found that appealing at the time, I can assure you my interests have since changed. A few years into using Angular, I fell out of love because of its complexity and sluggishness. Fortunately for me, Vue had grown up a lot in those years, seemingly waiting out my relationship with Angular. We’ve been together ever since.

While most of the Vue code that lives in the existing Cushion is Vue 2 with the Options API, I’m using Vue 3 with the Composition API, which is so much more TypeScript-friendly and reads like vanilla JS. When using <script setup>, any const or function is exposed to the template automatically, so it’s immediately familiar to any straight-JS dev and even more inviting than it was before. I could wax poetic about my love of Vue, but I’ll stop right here and save you all.

When we talk about frontend, we unfortunately still need to talk about bundling. Back in 2014, the initial build scripts for Cushion’s frontend used Gulp—remember Gulp?? Gulp existed well before we had hot module replacement, but we did still had LiveReload to refresh the entire page on save. For several years, I tried to migrate to Webpack, but gave up each time—those who have also tried know what I’ve been through. Then, in 2019, I successfully switched to Vue CLI, which does use Webpack under the hood, but at least provides a wrapper around it to make it less painful. Still, with an Angular frontend that has Vue embedded throughout, there was no way I could get HMR to cooperate.

These days, Vue CLI has been replaced with Vite—an incredibly quick, easy-to-setup, and extensible bundler and dev server from the folks behind Vue. I’ve been using Vite ever since building ProtoPen, my prototyping environment when I worked at Stripe. Like everything Vue-related, it speaks my language, and I just get it from the start. I’ve tried other frameworks over the years, like Nuxt, but the magic that happens behind the scenes always ends up causing problems down the road, and I always find myself needing to troubleshoot magic. To save myself the future headache, I’m keeping it simple, and sticking with straight Vite.

That’s all for the initial setup. We’ll see if these choices stand the test of time.

Reply via email

The past fews years leading up to this 10-year milestone, however, have been full of existential thoughts. When I look at where Cushion is now (and honestly where it’s been for the last ~5 years), I feel a sense of nostalgia and longing for the years before it—when Cushion was only me and only a side project. (Cushion currently is only me and only a side project, but I’ll explain what I mean…)

It’s easy to forget, but for a couple of years in the middle, Cushion was a venture-backed startup. In mid-2016, I made the decision to take Cushion to the next level, from a bootstrapped side project to a startup with a team and funding. That change significantly altered the trajectory and made Cushion more than only me and more than only a side project. I truly believed at the time that Cushion could be the only tool for freelancers, and I thought that’s what I wanted. While the bootstrapping years were as wholesome as it gets—with me casually whittling away at my precious object and consistently writing about it—the startup years were a nonstop sprint of aiming for the fences, under the gun of a dwindling runway, in a startup world where I always felt like an imposter.

In hindsight, I’m glad we tried it, but ever since those years, I can’t shake this aching feeling that Cushion is “off-course”. Instead of embracing what worked really well up until that point and doubling down on those features, we were always in search of the “network effect” that would grow Cushion exponentially. We spent months working behind the curtain on big features that would never leave private beta, while the rest of the app remained stagnant. I never felt good about neglecting the features that people actually used, and I felt even worse when I needed to cut our losses with the big features—erasing months of progress in the wrong direction.

Ever since the startup experience, I’ve had a theory brewing inside me—or rather eating at me. It feels obvious now, but it didn’t at the time: if I would’ve stopped expanding Cushion’s scope at the 2-year mark—when Cushion was thriving—and instead focused on growing the user base with the features that really worked well at that time, Cushion would’ve grown more while also being easier to grow, maintain, and improve. This makes sense now, but it didn’t cross my mind at the time—I’m a builder at heart.

Now that I’m on holiday break for a few weeks, I’m ready to test this theory. When I look through my journal posts and changelog entries, that 2-year mark puts us around early 2016—when Cushion was truly in its prime. The app was simple, focused, and easy to market. This is my goal.

In combination with this theory, I also want to introduce another thought: what would Cushion look like if it were built with a modern stack? Most of Cushion’s inner workings are at least seven years old, including a Heroku infrastructure, Ruby backend, and a frontend potpourri of jQuery, CoffeeScript, Angular, and Vue (from when I tried to incrementally migrate to Vue by embedding it within Angular…) After living with this codebase for years, I’m certain that a modern upgrade of Cushion’s stack would work wonders for consistent improvements—especially when what used to take weeks could now be done in a day or two.

A modern upgrade also brings another important factor—excitement. Legacy codebases can be draining, but one way to fight that feeling is to build a dev environment you’re excited to work in. 10 years ago, believe it or not, I was excited to use Angular and Webpack. Now, not so much. These days, I’m all-in with Vue and Vite, but who knows about 10 years from today. Regardless, Cushion is ready for a fresh coat of paint and a fresh new engine.

I could’ve written this post a week earlier with an outline of my plan, but I wanted to hold off until I actually started working on it—and I have. After a day, I already have the web app deployed and running with user models and authentication—including the addition of Google Auth, which would’ve been a headache to implement in the existing codebase. I’m really looking forward to seeing how far I can run with this, while at the same time only considering it a test of a hypothesis. Nothing’s set in stone, but this is what side projects are made for—trying things out and having fun.

Reply via email

Making a significant upgrade like this could be nerve-wracking, and it was, despite Cushion’s backend being incredibly well-covered with tests. After running the entire test suite locally, I was reminded that there are in fact ~5,500 tests for Cushion’s backend. This calms my paranoia when I need to make any backend changes, which is incredibly important for an app that’s over nine years old. Even so, with such a significant upgrade that involves a major version bump for both the OS and backend framework, I was still pretty nervous.

At first, I didn’t even know that Ruby would need a major upgrade as well, but I quickly learned this when my CI complained that Heroku 22 doesn’t support Ruby 2.x. I’d be the old man yelling at clouds about this, but it was fine. I should keep everything up-to-date for security purposes, even if I don’t need the shiny new features. When I bumped the Ruby version, I started to see the real work that needed to be done—217 failing tests. I know the exact number because I kept a log of my progress as I chopped away at it. Even with a number to track, however, I didn’t know the true weight of each failing test. A simple dependency upgrade could fix half of these tests whereas a single failing test could end up taking days to fix. Considering this unknown along with a tight deadline of May 1st, I decided to set up camp at my wife’s artist studio for an entire weekend and get to work. Luckily for me, that weekend was the start of the NBA playoffs.

After an entire 12-hour day (or four NBA playoff games), I was able to get the number of failing tests from 217 down to 161. This did feel like progress, but not as much as I had hoped. The reality is that this progress wasn’t a straight line. Halfway through the day, I had actually gone up to 228 failing tests.

With certain fixes, like updating a dependency to support a new syntax, you can sometimes end up with more failing tests because the updated dependency included breaking changes of its own. This means that it’s not always a given that I’d be making forward progress. It’s your classic one step forward, two steps back. I wasn’t deterred, though, because the test suite would always let me know exactly what broke—I never had to guess. After this first day of troubleshooting, I still felt accomplished because in addition to fixing dozens of failing tests, I also found my footing. I was now confidently wearing my backend hat, and I had momentum carrying me forward at a steady pace.

The next day, after another solid 12-hour day, I got the number of failing tests down to six. I couldn’t believe how much progress I had made on such an open-ended scope. I actually gave myself several weeks of lead time to finish the upgrade in time just in case. This shouldn’t be a surprise to anyone who knows me, but I’m often the person who arrives at the airport so early that I can take the earlier flight (and that’s happened!)

Fixing the final failing tests actually involved removing a feature. One of my bigger regrets with Cushion early on is that I decided to build custom integrations too soon. For a solo dev, integrations become a prime example of Murphy’s Law because 3rd party services tend to make changes without notice. You’re heads-down working on the new feature when a user points out that a certain integration isn’t working. You take a closer look and the service launched a new API that’s alpha and specifically says that it’s bound to change, but your integration relies on the rock-solid-but-now-deprecated API. It’s such a draining context switch. I should’ve just used a service that manages these connections for me.

Back to the feature in question—Cushion’s Xero integration. This feature has been a thorn in my side for years because their API requires a specific certificate-based authentication that’s strangely complicated and unlike any service I’ve authenticated with before. In addition, Xero calculates their invoice tax differently than every other service, so even if I imported invoice line items identically to how they are in Xero, there’s a chance the tax and totals are slightly different—not great when you’re dealing with currency. With all of these scars, and the fact that Cushion doesn’t have any active Xero integrations at the moment, I decided to quietly sweep it under the rug. I honestly don’t think anyone will miss it.

The following weekend, I merged the code, deployed to staging, and did a thorough click-through of Cushion’s staging environment. Everything seemed fine, so I went ahead with the production deploy. I truly didn’t know what to expect because these are often the moments where one unexpected hiccup occurs and melts your innards as you try to quickly troubleshoot the issue. Fortunately, this particular deploy went without a hitch. I was actually unsettled by how uneventful it was, but that’s the point—no news is good news. Over the next few days, I kept an eye on production, but everything was fine. I’m relieved, but also proud. I’m not primarily a backend dev, but when put in the situation, I can wear that hat. It’s also empowering because I know (with an app of Cushion’s size) that there’s nothing I can’t handle—even after all these years.

Reply via email