Early in a project, how an app works isn't set in stone. Later in a project, it very much is.

I just went and reviewed a complex web app we built. The Sembit team wrote 708 lines of code to implement a component for the main screen. Most developers average about 100 lines of tested code per day. Even though the average Sembit developer works at 5x or 10x that speed, it's still a lot of effort - a day or two of effort at least.

Now let's say we changed the design, and had to make changes to that code. That developer might need to find, change, and test 20 lines of code - doesn't seem like it would take much time right? And sometimes it IS a simple change. More often, however, the developer has to touch much more than just that one component. Instead, they might have to change that component, plus a model, plus a database table, plus an API call, etc. Additionally, changing something instead of building it correctly the first time can also introduce subtle bugs (just ask anyone who's ever been on a project that's "90% done" for months and months, while the development team "makes a few final changes"). This is why an apparently small or medium sized change to a design might require an extra day or two to code and test and deploy and communicate to the rest of the team.

This is why Sembit defaults to a design-first approach. We build complete high-fidelity Figma mockups of your system early in the project, let you review them, and quickly update them based on your feedback. Every change we make is to a visual mockup, not hundreds or thousands of lines of code, so we iterate orders of magnitude faster during this design phase.

We've also found that every hour spent nailing down design pays you back twice. First, it saves money overall due to less future rework. Second, and more important, it results in a better system. You may have an initial vision of your software, but you need to see it in order to have something to react to. Creating that visual, interactive view of your software sparks a reaction from your team in a way that bullet points in a specification document don't. And since it's just a design, you still have time to make adjustments before it's set in stone.

As a specific example, we recently did a project for Binster, who connect eco-conscious shoppers with quality items from local businesses through their digital secondhand marketplace.

Here's what Tammy @ Binster had to say about the process:

And that's the goal of design: to discuss those pros and cons early in the project, when it takes 10 minutes to change a workflow, not 20 hours.

If you think this might be something you're interested in discussing further, please reach out!