Sprint.ly’s New Pricing Model

image

Most companies in the business-to-business SaaS model work on a freemium model or a trial model. We are going to try both.

Gone are the days when you could make a simple software product that serves all customers the same way. We now have to design the whole product and the user experience around it.

These days, a complete product entails marketing funnel, onboarding, discovery, add-ons, and communication. Now we are trying to make a product that offers distinct benefits to different sized teams and people with different roles. Our design challenge is to create a product that can grow with the customer and retain them, while not being overwhelming at the start.

This complexity plays out in our pricing model as well.

We need a pricing model that gets us in the door, charges more as we provide more value to larger teams, and makes enough money to keep us in business!

So we’ve talked to our existing customers, former customers, and prospective customers and have tried to imagine and build a total spectrum product that addresses the problem of “graduation” - the movement of successful growing teams onto more enterprise- focused products.

Today, we’re happy to announce that we have launched a new pricing model. It’s sort of a hybrid between freemium (very small teams are free) and low-cost tiered plans, with high-value add-ons coming soon at most all levels.

We decided that our new pricing model must:

  • Have a free tier for small teams
  • Present compelling up-sell opportunities
  • Match price to value, and not be gimmicky
  • Encourage the adding of people to teams
  • Make sense for both makers and managers
  • Allow existing customers to retain old model if they prefer

We hope you love it. Let us know either way:

twitter: @sprintly​  / support@sprint.ly

Have some questions? Read some common questions from the Billing sections of our knowledge base

Sprint.ly Performance Update

Last week we launched a dramatic increase in performance for our front end. We are built on Backbone.js and, over time, our rendering times have slowed down. Luckily, using some of the great tools in the latest versions of Chrome and a few additional tools for instrumenting how the Sprintly frontend was performing, fixing it was dramatically easier than it would have been just a few months ago.


Analyzing the Refactor

After some initial testing of rendering times and analyzing performance data gathered with Caliper, we determined that the best way to get out from underneath lethargic performance with large item-sets was to rethink how item cards were being rendered throughout the app, with a focus on item columns. Item columns are containers for groups of item cards (stories, tasks, items and defects) and show up on the dashboard and items pages.


Item column views do *a lot* of heavy lifting in Sprintly, and since they were initially developed a myriad of features have been added, subtracted, balanced and adjusted, leading to optimizations for some scenarios but not others. We sped up item columns primarily by optimizing how item columns rendered and cached the individual cards that go into them—rather than re-rendering column contents when changes happen, cards are inserted, removed and re-rendered individually, leading to better overall performance everywhere item columns are in play.


Better Tooling

The new Flame Chart view for CPU profiling made it easy to spot and optimize areas in our app that needed a dose of micro-optimizations. Given that many of the performance enhancements focused on customers with the most items, relatively small improvements can have a big impact on the most intensive parts of the rendering stack: smooth scrolling / lazy-loading, resorting and switching between the dashboard and the items view.

 image


The notion of JavaScript and browser rendering “frame budget” was a focus of the performance refactoring and much of the speed improvements can from recognizing when the Backbone application was attempting to do too much during a given frame. Actions that trigger rendering/repainting, requesting data from local cache or from the API or binding events to the DOM are common culprits when trying to improve framerate.

 image


By using the timelines panel in the Chrome developer tools we were able to identify where bottlenecks were forming, and were able to move many rendering actions to be asynchronous, either by delaying them with a set timeout or a using requestAnimationFrame.


A big shout-out to Addy Osmani and his spectacularly titled blog post Taming The Unicorn: Easing JavaScript Memory Profiling In Chrome DevTools, which provided an excellent set of sign posts for wandering through the jungle of JavaScript heap dumps and CPU profiles.


It’s worth noting that while we were primarily measuring in the latest version of Chrome, there are good alternatives in the Firefox devtools, which we were consulting from time to time to make sure gains in one browser weren’t causing regressions in another.


Performance Monitoring and Measurement

We were able to consistently and accurate measure performance characteristics, which greatly influenced how we went about re-writing how item columns and item cards were being rendered to address these framerate, load time and rendering concerns.


Here are some of the results that were measured using Caliper from before and and after the performance release:


Before the performance refactor:

image

 

After the performance refactor:

image

 

Following the performance release, average rendering time was decreased on average of 30%, with an 11% decrease in 90th percentile rendering time and a 6% decrease on the median response. We’re going to continue measuring and quantifying frontend performance—and still have more speed improvements in the works.


We’ve noticed palpable difference in performance and have been hearing the same from some of our customers already. Rob Munro, CEO and Scotch Aficionado of Idibon, told us “We stress-tested Sprint.ly over the last couple of days a few times with multiple people searching/browsing/editing all at once. It went really smoothly - thanks for the great product updates!!”


Let us know if it feels good for you too.


Thanks so much to Quick Left, our pals in Boulder who helped bring all this impressive JavaScriptiness together.


About Quick Left: Quick Left is a consulting agency of technologists and designers located in Boulder, Colorado. Quick Left specializes in building custom web and mobile applications through a transparent agile workflow process. Contact hello@quickleft.com for more information on project estimates, developer resources, developer training and UI/UX design. Follow @quickleft on Twitter.

Sprint.ly Closes Seed Financing Round

We are pleased to announce the closing of our Seed financing round.  The financing yielded about a million dollars in new money for Sprint.ly to expand marketing and hiring.

We’d like to thank Freestyle Capital, our long time supporters, for leading the round that included some of our mentors and friends, completely new folks from AngelList , and for the first time, a few actual, living, breathing, current customers.

When a customer buys into our round we feel especially gratified that their experience warrants backing our company and efforts. We care deeply about improving the way software gets made. When a customer gets it, we feel great. When they literally “buy in” we feel even better.

The tools for financing companies continue to evolve (AngelList, KickStarter, etc.) and increase the democratization of company financing. We enjoyed using AngelList to reach the Angel investor community; we can see that this is world-changing, and we love it.

Now we will put our noses down and our fingers back on the keyboards. Hopefully it will be several months before we have to do another pitch meeting!

New Sprint.ly Search Backend

Hey Sprinters! We rolled out a new search backend today. This big win with ElasticSearch will allow us to greatly expand our search features in the course of the coming months.

In the meantime, our new search offers you some great immediate benefits:

  • Items and comments are indexed within a second or two. This means searching for keywords and terms from newly posted comments, updated items, etc. will turn up results immediately.

  • The Search field’s type-ahead will also return ALL results. We previously returned the top 20 hits and this may have inadvertently caused confusion.

  • We’re also weighting certain fields. For instance, we “boost” title over description, which means items with “internet explorer” in the title will show up before items with that phrase in the description. Additionally, we’ve boosted Backlog and Current items over other items. We’ll be continuing to play with these weightings in the coming weeks.

We’re very excited about this first step towards expanding our search capabilities and look forward to rolling out more search features for our Sprinters.  

You may learn more from our knowledge base article. As always, please contact us at support@sprint.ly with any questions.

Sprint.ly Backlog Management

Managing your project’s backlog can be an unwieldy process when you’re facing a long list of items. At Sprint.ly, we are project managers as well and use Sprint.ly every single day to manage our long list of iterations, releases and internal projects.

We created this simple walk-through on how to effectively manage your project backlog. Keep in mind that Sprint.ly was built for many different styles of project management. What we show you here what works for our team. We encourage you to use the flexibility built into Sprint.ly towards a method that works best for you.

Outage Report

Today at 10:03AM Pacific we began experiencing an outage that resulted in a total of about 15 minutes of intermittent downtime. Our TraceView graphs show a clear MySQL anomaly.

image

We use Amazon’s RDS product for managing our MySQL needs and Sentry for tracking exceptions from Django. When we looked into the graphs and error reports we noticed MySQL was having disk space issues. Our first thought was we’d ran out of disk space on our DB server, but Nagios didn’t report any warnings about us getting close to running out of disk. Upon inspecting the RDS graphs we found something strange.

image

Our best guess right now is that some operation caused a large temporary table to be created at 17:00 UTC. Our RDS snapshots are scheduled for 13:30-14:00 UTC, our maintenance window is Tuesdays from 10:30-11:00 UTC, and our weekly full DB backups run on Friday at 16:00 UTC. This leaves us reasonably confident it wasn’t a scheduled maintenance issue.

Regardless, we’ll be taking the site offline tonight in order to dramatically increase the storage available on our RDS servers. Customers can expect about 30 minutes of downtime around 18:00 Pacific (1:00 UTC). Thank you for your patience and our apologies for any inconvenience this caused you!

UPDATE: We have double checked our cron jobs and confirmed none that run at this time. Additionally, no large API requests were sent in this timeframe, which also has special checks to limit data sent across the wire to mitigate abuse issues.

Welcomes Phuong Palmares to the Team

First let’s get the obvious aside – how do you pronounce “Phuong?” It is pronounced as “Foo-ung.” Most Vietnamese and oddly enough, Spanish speakers can pronounce this name without much ado. Saying “Foo-ung” while gesturing a waving motion with your arm helps. If that didn’t work, you can just go with F-O-N-G. I’m good with either.

I joined Sprint.ly this September as the Director of Customer Success. It’s a pretty big and exciting title that means that I get to be the voice of our customers. I have served the better part of the past 13 years serving customers. After college I started in customer service at a DSL provider, taking on the most frustrated of customers who called in and demanded to speak to the CEO. Next, I moved into electronic discovery and litigation software. I trained, supported, project managed the world’s top lawyers (usually pretty non-technical folks) and corporations on how to use keyword search, concept search and automation to cull down petabytes of data into the most relevant morsels. These are the most relevant files to be produced into a court proceeding and it was all done on our SaaS-based software. It was here at Discovery Mining where I worked for our Sprint.ly CSO, Matthew Work.

Earlier this year Matthew introduced me to Sprint.ly and Joe Stump. I found Joe to be this enigmatic and passionate data wizard dressed up in tattoos and pink Converses. His ideas and plans for Sprint.ly are clear and are real market differentiators. I also found the incredible combination of intellect, creativity and forward-thinking approach from the rest of the Sprint.ly team as a rare find. I knew I had to be a part of this spirited Sprint.ly team. It is this talented Sprint.ly team that is the core of Sprint.ly’s culture and success. It is the faces above who build, deliver and service the Sprint.ly product that we all use as an integral part of our own business processes.

I’m honored to be the voice of our dedicated Sprint.ly fan base. Some of you have already seen my name come through your email inbox in the form of check-ins, offers for help, or surveys. I am serious about being the voice of users and am here to be of assistance. Thank you for taking the time to respond to my emails and my surveys. They lay a foundation for the exciting new things that you will see from Sprint.ly. I promise.  

 

Sprint.ly Welcomes Nicholas Serra to the Team!
Hey, my name is Nicholas Serra, and I’m excited to be joining the Sprint.ly team! I’ve been coding for over ten years, having spent the last few of my career at a small startup in Ohio.
 
I’ve spent some time doing agency work, which leads me to say that working for a startup is definitely a better fit for me. I thoroughly enjoy participating in the continuing evolution and progression of a product. From chasing bugs to developing new features, making improvements and optimizations to a codebase is something that I take pride in.
 
I first used Sprint.ly almost two years ago to aid in managing my previous team. My impressions were very positive and I recall thinking that the Sprint.ly approach to handling task flow was very different and refreshing. My introduction to the Sprint.ly team occured almost a year later when I signed on to assist the team with bug fixes and small features. My experience with the Sprint.ly team is one of the main reasons that I’m so excited to be joining. I believe that it is especially important in this industry to surround yourself with people that are motivated and have fresh ideas. Fortunately, they are a group of very talented, creative, and easy going people who I very much enjoy sharing an IRC channel with on a daily basis.
 
On top of the team, Sprint.ly also happens to have an awesome and active user base. It’s these users that serve as motivation to me to continuously push out features and improvements to the system. Looking to social networking or direct customer feedback and seeing positive comments and constructive criticism is definitely a driver for me personally.
 
And of course, I just think that Sprint.ly is a useful piece of software. I’ve used far too many project-management type systems in the past with unfavorable results. Sprint.ly has been the right tool for the job for me on multiple occasions. I also really enjoy the fact that the team uses Sprint.ly to develop Sprint.ly. Improvements, features, and bugs are all tracked within the Sprint.ly project in the same way a customer would track their own product.
I look forward to working with the team full time to continue releasing features and fixes that improve user experience and Sprint.ly as a whole.
 
Bill Gleim Joins the Sprint.ly Team!

My name is Bill Gleim, and I’m the latest member to join the team at Sprint.ly. I’m excited to join Sprint.ly - let me tell you why. I used Sprint.ly professionally before ever thinking about joining the team. The team is led by a guy that friends have brought to my attention randomly in the past, Joe Stump.

After looking further into Sprint.ly, I developed an impression of Joe Stump watching videos of him evangelizing his approach to startups & project management. His philosophy of eliminating friction within a team by promoting transparency is infectious. His philosophy of eliminating friction by promoting transparency is embodied in the sprint.ly product.

I come to the Sprint.ly product development team from a background of human-computer interaction and machine learning in academia. This academic experience is balanced by a decade-to-score of hardcore software engineering across large & small organizations, including as founder of two companies. My focus at Sprint.ly will include large measures of algorithmic modeling and, perhaps, data modeling [the distinction between the two is discussed at length here ].

My engineering approach to creating algorithmic or data models is fundamentally based on my experience in modeling language development. I modeled language development under National Institute of Health grants in the following capacities: (1) brainwave analyses at the Salk Institute in San Diego, (2) behavioral analyses at the Language Research Center of Children’s Hospital San Diego, & (3)algorithmic modeling at the Center for Research in Language at University of California, San Diego. As a result, I do not look at data as a general statistician; rather, I look at the world in terms of the algorithmic modeling of time series data. In particular, I pay attention to structural patterns in time that emerge from complex systems. What can organizational data tell us about the limits and boundaries and norms of how organizations function? How can this information be re-purposed to better serve these (& other) organizations? How can this be executed not just from a data harvesting perspective, but also a human-computer interaction perspective? These are the long-term challenges that I am excited about tackling.

As a team, we will first be re-structuring our text-based search to produce more relevant results & to include natural language capabilities in our search model. Look for exciting changes to come. The better we make the Sprint.ly product, the more our customers can achieve.

Sprint.ly Welcomes Flora Worley to the Team!

Hi, my name is Flora Worley and I’m very happy to be joining the engineering team here at Sprint.ly! A little about me: I arrived in the tech industry after making the difficult decision a couple of years ago to leave PhD studies (media/cultural theory) at the University of London. If at any time in my student life someone would have said, “you’ll end up in computers”, I would have laughed; but I’ve found that working in code is more like an extension of my research work than a departure from it, and in all the best ways. It’s analytical, challenging, and a tremendous growth experience, and the open source and startup communities offer many opportunities for engaging in meaningful ways.

I’ve been co-organizing the Portland chapter of Pyladies (our mission is to bring more women into the Python and open source communities) since its founding a year or so ago, and it is through this group that I met Justin Abrahms. Justin has become a friend and mentor, and I’ll admit that I’ve experienced workplace envy around him on more than one occasion. Who wouldn’t want to work on a super-talented team that cares as passionately about their product as the team at Sprint.ly does? Justin took note of the fact that after some months of happy hacking on Django projects I’d wanted to work closer to the user experience, and so he brought me in to talk to Joe Stump.

Joe’s passion is infectious, and his vision for the future of Sprint.ly is exciting, deliberate, and grounded in experience building successful products—a rare combination. Add to that all of the little things that make Sprint.ly an exceptional company: transparency in process (as this blog attests), prioritizing diversity, an emphasis on collaboration and skills-enhancement. I’m really looking forward to being a part of the future here, and to working on creating a seamless experience for our users. I may be an engineer now, but I still consider myself a user first and foremost!