November 5th, 2025, posted in for_founders
by Miruna
Jumping into code with no design is like baking without a recipe. You know you’re supposed to use flour, eggs, milk. But how? In what quantity? How long do you let it bake for? Do you have to let the dough rise?
Just like baking, building software can’t be done unguided. And our biggest guide in recent years has been design.
Instead of building software code-first, we spend more time understanding the app concept, key users and desired functionality, so that we can fully design the app before coding it.
This way, we know what the app will look like and how it’ll work, way before it actually comes to life. It’s a great way to brainstorm, to reiterate, and to help product owners or clients see what they’re going to build before they spend thousands of dollars.
In this article, we’re going to explain how we do design-driven development and why it works so well for us.
What is design-first development?
You might be a bit confused. What does design-first development even mean? Do we design development? Do we make code pretty? Well, sort of. Design-first software development is a methodology where you fully design a piece of software (that means all screens and functionality) before you go into code.
This is opposed to building software code-first, based on a list of key functionality or full-on user stories. When going development-first, you skip app designs and user flow brainstorming meetings and start right away with code. You still know what the app should do, but none of the how and why. You find out what it looks like and how it works only at the end, when most development is done and the app can be tested.
In the case of design-first development, you take the time to understand the app, the user base, why it needs certain features, and how to implement said features so they serve their key users. You build every app screen with full detail and cover all possible user flows.
This allows you to get a detailed preview before months of software development. You get to see what each screen looks like and how it all flows together - it can even be clickable if you wish so. This way, you can reiterate, remove or add features, change UI elements, or even decide not to build the app at all. Way before you spend thousands of dollars on code. It aids in business decision-making.
In other words, it’s a lower level of commitment compared to a development-first approach: coding an app, even small, can take up to a few months. While the UI/UX design portion can be done in a few weeks, especially with a dedicated designer (who’s working on the app full time). In just a week or 2, you can go from idea to final designs, which, with the power of prototyping tools in Figma, can be clickable as well.
This is especially useful when you’re launching a new product as an MVP, and you want to test the waters before going full-speed with a large, complex app that could take 6 or more months to code. It’s a great way to quickly test your app concept and the usability of the first design.
Compared to a fully coded app, making changes to an app’s design is much easier and faster. You can change your mind about styles and features without waiting months for those changes to be coded. As long as the design is well-structured, it can be updated very quickly.
Step 1: Knowing the how and why
The first stage of building design-first software covers the “why”. You want to build a piece of software but why? Who is it serving and why that audience base? Why do you want to include your desired features? Why do you, in particular, want to build it?
Such existential questions don’t require a smoke pipe and a lit fireplace. When embarking on a software development journey, you should know exactly what you’re making and why. Building software just for the sake of it is inefficient - it’s thousands of dollars you’re spending, and you should do so wisely. How will it benefit your business and customers?
Knowing what you’re building is a key part of design-first software development. When you hire a team like ours, who outsources software, you need to be able to explain what you’re looking for. And that’s because we’ll have to take your ideas and requests and use those to fully design the app.
In this stage, we hold meetings with the app stakeholders or product owners to discuss the app’s requirements together. In these meetings, we sit down and brainstorm key app info such as user types and main features. We map out what each user type should be able to do, key functionality the app should have, and the stakeholder’s desired look & feel, should they have one in mind.
This is where we do user research, and with business-facing software we rely on the product owners for information, especially with more complex industries where you can’t find data simply on the internet. When it comes to customer-facing apps, the best approach is to find potential app users and hold interviews about their day to day life to try to find the best ways to include the app in it. We go more in depth about user interviews in this article.
Step 2: Building software design-first: mapping it out
Once we know what we need to build, we head straight into UI/UX design. Just like the “design-first” name implies, design is the key part of design-first development. This is an important step where we map out every page, button, functionality, user type, user flow, you name it.
Our design process usually goes through the following steps:
1. Setup
In the setup stage, we decide the overall style of the app. We set up color and typography styles in our Figma file, and based on those, we make a few key components to reuse across the app. We usually make buttons, form items (input fields, checkboxes & radio buttons), dropdown lists, search bars, toggles, and any unique items we might need for that specific app.
Example of our Figma setup
2. Designing core screens.
Once we’ve got a clear style, we can start designing a few core screens that will set the tone for the rest of the app. We build a lot of CRMs, which means we make a lot of tables. Once we’ve made one, we can reuse it across the app. Core screens in most apps we build are usually the dashboard, a table list page, an item creation page, onboarding, and a complex screen specific to that app (may vary).
3. Designing all user flows
This step often takes place once we sat down with the app stakeholders and approved the first iteration of the design (those core screens we just talked about). Before we design the entire app, we make sure the overall style is final, as it’s quicker to edit the first few core screens as opposed to the whole thing.
Since our core screens will always include the sidebar menu, which features all app sections, we design all pages covering those sections. We cover dropdown lists, pop up actions, alerts and confirmation pop ups as well.
If we’re building an app covering multiple user types, we usually design the highest level user type (usually called the “super admin”) and work our way down until the user with the lowest level of permissions.
4. The feedback - reiterating - approval cycle
It’s not really as simple as “just design all the screens”. In order to make sure we’re on the right track, we hold regular meetings with the app stakeholders. We showcase the screens we designed, gauge their thoughts, and make sure they’re okay with all the user flows, styles, and the screens overall.
So we don’t just design every screen back to back, approve, go into code. A lot of the time, we get feedback, make several updates, and once the app stakeholders are happy, we move onto development. This is just to ensure we get it all right and the entire team is up to speed.
5. Writing user stories
In our process, the designer’s job doesn’t end when the design is approved. User stories are a key part of software development, as they map out all app features in detail and serve as a guide for developers on what to code. Our designers know the ins and outs of our apps the best, so they’re usually assigned this role.
User stories are both helpful in guiding developers and well as in creating cost estimates for the app stakeholders. Our developers use the user stories to estimate how long each feature will take to code (in hours), so we can later tell our clients how much it’ll cost to build the entire thing.
Step 3: bringing it to life
Once the design, user stories and budget are all approved, we head into code. Since the app is already fully designed, the developers don’t need to worry about deciding on styles or themes - they just need to know their way around the app’s Figma file.
The user stories we mentioned earlier are turned into ClickUp or Jira tasks, whilst the design is attached to each of them as the main visual reference the developers need to follow. The dev team and the project managers usually sit down, assign tasks and decide the order of things - what needs to be coded first and what can come later.
The app’s design is used as a reference the entire time - our developers follow each pixel to the T and make sure they implement the design the exact way it was approved by the app stakeholders.
We go more in depth about our software development process in this article.
Once the first iterations of the app are pushed to a staging environment (that only the internal team can access), our quality assurance team goes through it and ensures all the user flows work as intended. They also check if the app’s UI is up to par with the Figma design - and they’re pretty unforgiving.
Testing is a big part of this process, as we have to ensure we implemented all that product discovery hard work, and that it wasn’t for nothing. We also allow clients to test the apps themselves, especially if they’ll be the main users. This is especially important if they need to import their own data and test realistic use case scenarios.
Step 4: launching and continuous maintenance
Congratulations, your app is live! But the work is not over. Once you’ve launched, oftentimes you start getting feedback from your users. And they might consider some features incomplete, working inadequately or they might want to request features you didn’t include.
In these cases, it’s essential to stick around with your dev team and iterate the app to keep your users happy. Most commonly, we’ll take the time to design these updates, estimate their duration & cost, and then code them. All to ensure the final product is exactly what you asked for - and you get to see it before weeks of code.
Just like the main app building process, designing new features before coding them is a great way to see what the updates will look like before you pay for development hours. You get to brainstorm and A/B test your ideas way before launch, to ensure you’re making the right decision.
This method also works great if you’re adding onto existing software instead of building something from scratch. Just keep in mind - if you don’t have design files for your existing app, the design team you hire will have to take the time to accurately recreate it.
Overall, building software design-first is a much more efficient methodology. You’re being more meticulous and showing more care for your users, which will translate through the software itself. It’s a great way to build software that serves its users and which you can easily brainstorm upon.
Looking to build software design-first? Contact us and let’s see what we can do together.
