As a consulting company, we review a lot of potential projects. How do we find those that are a good match for our expertise, culture, and that we can successfully sign a contract? The short answer is: it takes a lot of work. One step in the evaluating process is to estimate how much it would cost a potential client for us to build their project, and how long it would take. This post is the first of three that provide an in-depth walkthrough of how this happens at Quick Left!
The tech world moves fast. It's not uncommon for a startup to scale from two people in a coworking space to a team of thirty or more in a matter of months. Just as often, the team shrinks again due to sudden market changes or errant developers moving on to the next big thing.
When you're getting ready to rebuild, it can be hard to know where to begin. There are so many things to do, from marketing, to onboarding a new team, to deciding what to build next.
In part one of this series, we talked about some of things you can do on the technical side to get your dev team up and running with a minimum of fuss.
In this, the second and final part of this series, we'll focus on how to prioritize your best features. We'll look at how to decide what you should get rid of and what you should pull out into its own codebase. Then we'll tackle the question: what to build next?
Recently, a client of ours asked us why our developers split front-end (client) and back-end (API) code into two repositories. In this blog post, we'll highlight six reasons for splitting client and API code into two repositories.
- ← Previous
- Next →