Skip to main content


We're designers and developers. We want to design and develop software. Before we can do that, we need clients to hire us.

The overall process is:

  • Someone contacts us via our new project form, phone, or email.
  • We have a video call or have them come into the office.
  • Qualify/disqualify: are we a good fit for the client?
  • Qualify/disqualify: is the client a good fit for us?
  • Understand the client's vision.
  • Agree to the outcomes we're trying to achieve.
  • Estimate iterations.
  • Sign the contract.
  • Pay us for the first iteration.
  • Schedule people for iterations.
  • We begin work.


Our leads often come from referrals from clients and Google searches.

We track each lead in Zendesk Sell.

We manually create Contacts for personal introductions. Our new project form automatically creates leads for each submission.

The Managing Director in the location will get notified about the incoming lead, but anyone can take responsibility for it. The person responsible qualifies or disqualifies the lead, often with a quick intro email, phone, or video call with the potential client, before they move the lead forward in Sell, which will change them to the owner.

We prefer to pair on sales calls, having at least one designer and one developer on the call. This enables us to get multiple opinions on how good or bad of a fit the client and project might be for us, it gives us the ability to answer both design and development questions to the best of our ability, and it allows us to train and improve our process during sales calls.

Understanding Product Vision

Our goal is to begin thinking about the client's product and working as a team to plan it even before we officially start working together. Some example questions to ask:

  • What's unique about this product?
  • What big benefit does the product provide?
  • What pain does the product alleviate?
  • Who currently buys this product?
  • Who do you want to buy this product?
  • What do customers love about your product?

We distribute the sales process throughout the team. Potential clients should be able to talk to the people they'll work with. We should be able to handle spikes in incoming leads that make it unreasonable for a Managing Director to respond in a timely fashion.

We use an internal app to manage our schedule and availability. We don't track time, but we do plan in week increments.


If the client asks us to sign an NDA, we respond with:

Are you willing to chat without signing an NDA? We've worked with hundreds of clients. We talk to hundreds of potential clients each year. It's inevitable that we hear similar ideas.

If the NDA is important to the client, ask them to tell us enough about the business to evaluate whether there's a conflict with our existing or past clients. If we determine there's no conflict, the project is a good fit, and the NDA is mutual, we sign it. If their NDA is not mutual, we use our NDA.


We offer some combination of designers, Ruby developers, and iOS developers. An advisor assists the team for a few hours a week. Everyone is T-shaped, deep in some area of expertise with the ability to collaborate across disciplines.

We are people, not "resources", and avoid calling each other such because we understand we are working with each other as people.

The designer is responsible for designing interactions between users and the product. They write user interface code.

The developers make it work. They write the code that makes the app "smart." They aim to make the product error-free. They monitor performance because speed is a feature of every application.

Developers keep it running. They make architectural decisions and interact with modern-day hosting companies like Heroku, whose employees double as our outsourced operations team.

The developers also implement. They write and maintain HTML, CSS, JavaScript, Ruby, SQL, and lots of other code. They set and meet development standards, keep the Continuous Integration build passing, and review each others' code.

The advisor adds an impartial perspective. They run weekly meetings so that there is consistency in week-to-week communication. They keep an eye on the high-level goals of the project, which should be easier for them because they are not in the weeds of the project day-to-day. They express enthusiasm when the team is in a groove and help problem-solve when things get off track.

When appropriate, they should work with the client to either reduce or increase team size to correctly serve the project.

The advisor is not a project manager. Nor do they take the primary responsibility for the project away from the team. The rest of the team does not report to them. The advisor is also not a technical or design lead.

Additionally, the advisor may:

  • help the project team work together to form an initial backlog, probably about 2-3 weeks worth of stories,
  • identify specific behavior from the client or team they think might signal a mismatch in understanding and bring it to everyone's attention,
  • run a training session for the client on the finer details of working with us, e.g.: what makes a good story, how to bring concerns to the team, walking through complexity vs. planning, and how we would advise dealing with it,
  • coach the client over the first two weeks in terms of how we might need more input in some places, but less in others.

Anyone at thoughtbot should be able to advise a project. If the primary salesperson is not also the advisor, there should be a detailed hand-off from one to the other so that details are not lost as the team starts the project.

There may also be a separate account manager for a client. This may happen if the account manager typically led the initial sale, but is not the advisor, or if a client has multiple projects with multiple advisors. In these cases, the account manager is responsible for maintaining a lifetime relationship with the client. They understand the client's needs and budgets, and how thoughtbot can meet those needs. They identify opportunities for working with a client, they coordinate scheduling, and manage invoices for the client's projects.

While each person plays a role, a team needs to be a team.

Everyone takes responsibility every day for delivering high quality work, for staying true to the vision for the product, for communicating their schedule and intentions, for making hard decisions, for delegating to others when they don't have the time or skill to accomplish a task, for keeping team morale up, and for being consistent.

No Fixed Bids

Some consulting relationships start with a requirements document or RFP ("Request For Proposal"). The requirements are often extremely detailed.

The probability of this document containing the optimum feature set is extremely low. The right features are better learned through user interviews, prototyping, releasing actual software, and getting feedback from real users.

Based on that document, clients expect consultants in the industry to submit an exact timeframe and bid. This contract style sets the client and consultant working against each other right from day one. Instead of focusing on designing the product experience or evaluating what assumptions were wrong, they spend time negotiating about what was meant in a document written a long time ago or focusing on arbitrary deadlines. But it's worse than negotiating; it's retroactively discussing something that no one remembers the same way.

As you might have guessed, we don't do fixed-bid, fixed-feature-set proposals.


We do need to know clients' budgets. This is often uncomfortable for them but their budget helps determines what scope is possible. It saves time. If they don't know their budget, we discuss different options.

We talk about breaking product rollout into stages and try to improve the product's chances of success at each stage by:

  • Focusing on a small subset of features.
  • Designing a valuable user experience.
  • Developing a meaningful relationship with users.
  • Budgeting for marketing tactics to tell users about the product.
  • Designing interactions into the product for users to bring other users to the product.


We price projects at a per person, per week rate. We consult 4 days per week. We use the same rate for designers and developers. The work required for each week dictates which skills are needed. The number of people needed determines the cost and how much gets done.

During the process of explaining our billing, we sometimes tell potential clients "time and materials" is the same as hiring an employee for their annual time except there's less risk to them because:

  • Our team is experienced. We've interviewed more than a thousand candidates in order to find the talented group of people we work with today.
  • We've worked together on projects before. We have "a way" of doing things.
  • Short projects require less money.
  • Our time is predictable (4 days/week) and consistent.
  • We can quickly rotate in a new team member if someone gets sick, leaves the company, or is ready to rotate to a new project.

We don't provide itemized invoices to clients showing individual pieces of work that were done. Clients always know what is happening via access to the project management system (Trello), chat room (Slack), version control system (GitHub), and ongoing communication with our teammates.

Typical Projects

Examples of typical projects for us are:

  • "Product design sprint", 2 people, 1 week
  • "Idea to Version 1", 3 people, 8-12 weeks
  • "Fill a gap until an internal team is hired", 2 people, 3 months
  • "Staff augmentation with existing internal team", 3 people, 6 months

On many occasions we've done projects for clients who have a budget enough for a "Version 1" product. They followed that up with a round of beta invites, time spent learning in the market, a round of funding, or a few months of revenue. They come back for another round of design and development with a more informed sense of where the product needs to go.

The feature set of a product is not necessarily indicative of the length of time required to develop it. Sometimes to get to a very simple product, we have to iterate on it many times. We love working with clients who understand that a great product takes as long as it takes.

In return, we understand that we can never abuse a client's trust in us. We should be maximizing our productivity in order to provide them the most value for our time. Things like our "Research" Trello board, "Code" internal chat room, and shared dotfiles ensure we have a highest common denominator set of tools and techniques ready when the situation arises again.


We store contracts in Dropbox and have a series of folders for pending, current, past, and lost clients.

The consulting proposal and contract contains:

  • A one-page summary of the expected work.
  • Our weekly rate.
  • Net 15 payment terms.
  • Payment for the first two weeks is required to start working.
  • After the first two weeks, invoices will go out once a week on Saturday mornings for the prior week's work.
  • Agreement that the client owns the week's source code once they've paid their weekly invoice.
  • Agreement that both parties won't use materials which break someone else's copyright.
  • Agreement that both parties won't publish things to the web hosting provider which are abusive or unethical.
  • Agreement that the contract is mutually "at-will" and either side can decide to stop work at the end of a week.
  • A page for signatures.


We use Quickbooks and to invoice our clients at the end of each week.

Clients can pay their invoice via check, ACH, or wire transfer.

Talk to one of our product experts about building success into your process.

This site uses cookies. Learn more by visiting our privacy policy.