Continuing my work on Cushion’s new invoice form, I caught myself doing what I often do—spending more time on potentially unnecessary details instead of taking the next steps to launch. At the same time, because I’m no longer reliant on Cushion’s income, being able to spend time on these details without any sort of deadline is a value in itself, so I’ll try not to be too hard on myself. Instead, I’ll be proud that I still care about the details.

On this theme, I’m dangerously close to getting the invoice form to a usable state. There are certainly a handful of ship-stoppers that still need to be addressed before GA, like adding new clients, contacts, and projects inline, or importing time-tracking entries, but it does feel ready for brave volunteers to beta test with several asterisks. That said, I’m less eager to release early because organizing that is a job in itself, so for now, I’m fine with tackling the remaining to-dos. A recent frustration of mine has actually led me to an idea that might help me out here.

Of Cushion’s signups, there are serious users, product designers looking for “inspiration”, bad actors, and people who don’t remember signing up. The last three have been wearing on me, but I do see the value in folks trying Cushion without being a freelancer themselves—maybe they’ll recommend it to their freelancer friends, etc. While I’m tempted to go to the extreme and add a lot more friction to signups—like confirming their email before onboarding, requesting an invite, or requiring a card—there’s a way to make this less extreme while still letting folks see what Cushion can do.

The idea, suggested by my fellow stripe Matt Basta, would be some sort of “test mode” for people “who genuinely want to kick the tires”. When I hear “test mode”, I think of Stripe’s in-app way of switching between test data and live data, so I’m definitely not doing that. But in this case, a test mode could be a version of Cushion that uses a session store instead of a database. If a user tries it out, there are no API requests or persisting data—saving an invoice would simply add it as an object in the local store, and refreshing the page would reset everything to the original state. This could solve my problem of bad signups, but it could also help me build Cushion in an abstracted, store-agnostic way.

While the super optimistic side of me loves the idea, the realistic side of me worries that it might be easier for folks to do bad things, like copy the code. I know this might be paranoid, but Cushion has a long history of people being turds. At the same time, anyone could sign up right now for an account and inspect the code just as easily. Maybe my saving grace at the moment is that the old Angular code is so rough that people give up.

In any case, I like the idea. Being able to have folks test something in a sandbox as I’m building it makes me feel better about “releasing” early. I’ve definitely learned that as soon as you release something, people will use it and expect it to be usable forever—even if there’s a beta label all over. Hopefully this can help with that, too, as a way of letting folks test parts of Cushion fully knowing that any “saved” data will be reset on refresh. …Or maybe I’m just setting myself up for folks thinking test mode is the real app and freaking out when their data doesn’t persist.