Currently, when you sign up for Spreedly, you get a free test site and an (inactive) production site. They’re yours and yours alone, and it’s hard to share access to them with other people on your team. Also, if you want to use Spreedly for another business, or run some experiments in a fresh test site, you have to sign up for a new user account with a fresh email. While this worked OK to get Spreedly launched, it’s become a major thorn in the Spreedly teams’ side, and we’re sure our clients find it bothersome as well. It just doesn’t fit the way businesses and teams work, and it needs to be fixed.

If you’ve done any web application development (and I’m sure a lot of you have), then you know that the challenge we face is that the account/site structure is a fundamental part of the application, and changing it is a pretty big deal. And yet we have to tackle this now, for two reasons: first, the longer we put it off, the harder it gets, as the application continues to become dependent on the current structure. Second, there are a lot of smaller tweaks and features that are getting backed up behind this larger task. As our designer put it, it’s hard to think about designing a place for a new feature when you know that it’s just going to have to change again once we add multi-user access.

We’re currently in the process of making this change, with some preliminary work on it already rolled out. If you have a Spreedly account, you might’ve noticed that a bunch of settings moved from the “Your account” page to the “Site Details” page. “Site Details” actually used to be “Site URLs”, and we’ll probably be doing more cleanup work in the site configuration screens as we continue working on this.

So what’s the end goal? Basically, you’ll be able to have as many Spreedly sites as you like, and you’ll be able to invite others to have access to your sites and in turn be invited by others to have access to their sites. So a developer can sign up, get a test site, work on it for a while, and invite other folks on the development team in to help out. Then the person paying the bills can sign up, create and activate a production site, and invite a developer in to hook things up.

The new structure of things will mean API changes, but Spreedly already supports API versions, so you can continue using the current (v3) API uninterrupted until you get a chance to update things. And we’ll of course give everyone a heads up through all the available channels when this goes live – we’ll be pretty excited to get you trying it out.

Is there a lesson here for those of you currently building web applications? I actually think there are two competing lessons. The first one is that you should release early, and stop worrying if you got it all right. You didn’t, but so long as you have good tests (you do have good tests, right?) then you can always change it later, as we at Spreedly are doing now. The second, competing lesson is that it’s worth spending a few minutes contemplating your collaboration model early on, since it’s so fundamental to your application. If you’re going to want multiple people to be able to access a particular thing in your application, it’s worth not painting yourself in to a corner that makes that difficult.

Two competing lessons, both important, but if I had to prioritize, I would say that lesson one – release early – is far and away the most important. You don’t have a business until you’ve released, so go ahead and release already! It won’t be right yet, and that’s totally OK.

We’ll keep you updated as we work to roll this out – don’t hesitate to hit us up with questions in the comments or at support@spreedly.com. Thanks!