Timelines

Timelines in Web Development can be tricky, and so we are testing a new system that puts you, the client, in control.

NOTE: The post below is very outdated info referring to SwiftCloud 1.0, the .IO platform instead of .AI, the 2.0 platform. We’ve left it up, because it’s conceptually still relevant, but portions may be outdated.

Timelines on Swift Web Designer / Swift Marketing projects can look complex – but it’s designed to empower you, the client, to take control over delivery dates & budgets.

Also, note fast, quick, easy projects i.e. < 4 hours have little risk of delays, while large complex projects have more moving parts, more chances of interruption, more communication required and thus are exposed to greater risk of delays. We are scientific about managing the time required for a project and aim to put you in control.

First, projects get delayed for 3 possible reasons, generally speaking:

1. Queue. At any given moment we have multiple projects in process, and so getting to top priority takes a bit of time. We’ll do our best to communicate where you are in the queue. We are experimenting with 3 time “modes”, each reflected in the budget:
   1. Urgent / Emergency / Top Priority (100% of Required Time). This has to be done yesterday AND you’re willing to pay more for this. There’s no queue: we start immediately, however, we can only take this if someone else isn’t already on this plan. If they are on this plan, we’ll advise you of the expected completion time.
   2. Normal Mode (200% of Required Time), which includes 2 timelines: Target (slightly optimistic best guess (but not overly optimistic) timeline), and Commitment – we’ll guarantee to be done by this date, or have financial repercussions.
   3. Pre-Emptible (400% of Required Time). If you beat us up on rate and truly want to save every penny, AND have some time, this allows other higher-paid projects to cut in line in front of you, though we’ll still have a guarantee date. As your project gets closer to the Guaranteed Delivery Date, we’ll make it higher and higher priority. As the old phrase goes, “Good, Fast, or Cheap – pick any two”. We only do great work, which leaves “Good and Fast” or “Good and Cheap”. “Fast and Cheap [meaning it’s not good, it’s bad]” is not ever an option for any Swift company or product.
2. Feature Creep. This is when bells and whistles get added to the project after starting, and/or there is more micromanaging over details – which is fine, you just have to pay for it. As bells and whistles are added, it adds time.
3. Wrong Direction (Rare) and/or programming not going as expected. On occasion, it happens (less than 5% of projects), the design goes “sideways”, meaning we’re given some ideas and notes, then need to trash some work and back up and pick a new direction. If we are on the wrong path, i.e. from a design perspective, don’t wait. We’d rather have too much info than too little – show us stuff you love, stuff you hate (because that’s useful to show us “not that”).. the more you show us, the less we have to read minds. While we try to be psychic, and most of the time we’re on target with minimal direction, on occasion a client doesn’t love our first sketches, so we get back on track. Note that we are pretty good at picking this out up front, and depending on your design package (see methods below). From a programming perspective, we have a lot of experience, and most of our projects involve minimal programming, and if there’s any programming, it’s “standing on the shoulders of a giant” i.e. our existing code base, so the risk here is minimal. Nonetheless, it could happen, though 9 times out of 10 we don’t have bugs, but “mis-configuration” meaning the programmer’s code is fine. The problem arises from communication – nonetheless, this can be minimized through “good specs”. For simple projects we’ll skip right to “beta’ – a basic working version and you’ll see it develop, while complex projects might have “alpha” then “beta” – a more crude skeleton that works, usually building just “the heart” first then adding limbs and other functions. Other times, certain components are beyond our control – i.e. use of APIs (application programming interface, a way for computers to talk to other computers directly) so we’re giving a best guess about how complex a task will be.

We spell this out to put you in control. From our perspective, we need to run a healthy business, and you’ll benefit from our critical mass of constantly incoming projects. We often go back, months later, and upgrade clients (for free!) to better systems, because we developed related code for some other industry and/or territory.

In the coming weeks, you’ll see what might seem like a lot of information, and moving forward, our project quotes may get a bit more complex around the timelines, however, we believe this is the only path to keeping clients happy and delivering with integrity. For clients who need faster turnaround, you have the power to get that with a corresponding budget, and for clients who push for a lower price, we then need the ability to prioritize higher-paid projects.