Building Software That Actually Gets Used
When I first got into software, I focused on the sexy stuff. What tech stack are we using? What does the loading bar look like? Can this scale if we grow?
I was on a call yesterday with my design team, refining Lawbandit’s design. We wrestled with a few new features even though the existing version works well.
This tension between "more features" and "simpler experience" shows up in every software project I've worked on—from project management dashboards for construction teams to lead tracking systems for real estate agents. After building dozens of these systems, I've learned that complexity does not solve problems.
Complex software sucks.
Here's what typically happens when you're building software (illustrated by a construction client we had):
Week 1: "We need a basic way to track project milestones."
Week 3: "Can we add photo uploads for each milestone?"
Week 5: "What about automated reminders to contractors?"
Week 7: "Should we integrate with their existing scheduling system?"
Week 9: “Maybe we need different permission levels for different team members?"
Each request makes sense in isolation. But by week 9, you've built something that requires a manual to use instead of something that solves the original problem quickly.
I see this constantly in the real estate and construction world. Companies start with a simple pain point—like "we lose track of inspection photos"—and end up with a system that's supposed to manage photos, generate reports, send client updates, track budgets, schedule appointments, and integrate with three different existing tools.
The result? Nobody uses it.
Build simple software.
Simple doesn't mean "fewer features." It means "fewer mental steps to get value."
Take our Lawbandit flashcards.
The complex version might have:
Different study modes (spaced repetition, priority sorting, etc.)
Animated card flips
Progress tracking
Social sharing
Achievement badges
Multiple card designs
The simple version has:
Create a set of cards
Study the cards
See question and answer clearly
Guess which one students actually use to study for their exams?
Using the software is the best test.
I learned this lesson the hard way, building a project management system for a residential builder. They tracked materials, inspections, and progress photos across multiple spreadsheets. Perfect automation opportunity.
The first version we made was beautiful. Real-time dashboards, automated status updates, integration with their accounting software, mobile photo uploads, and automated client notifications. The works.
Two weeks later, they wanted to scale back.
Why? Because entering data into the system took longer than updating their old spreadsheets. The superintendents had to remember login credentials, navigate through multiple screens, and figure out which dropdown menu contained "electrical rough-in complete."
The spreadsheet required typing "electrical done" in a cell.
Version two was embarrassingly simple: a single page where you could mark items complete and upload photos. That's it. They've used it for over a year.
The 95% Rule
Build the thing that solves 95% of your problem perfectly, not the thing that solves 100% of your problem adequately.
That missing 5%? It's usually edge cases that happen once a month. But trying to solve for every edge case upfront makes the daily experience worse for everyone.
Simple systems get adopted faster. When adoption happens faster, you see ROI sooner. When you see ROI sooner, you can justify building the next improvement. Complex systems sit unused while everyone waits for "proper training" or "when we have more time to learn it." That time never comes.
Software is a tool. The best tools feel like natural extensions of how people already think and work. Your business software should feel the same way.
-Adan
BTW, we build and implement software like this every day for different kinds of businesses. If you’re ready to save time and money with simple, custom software, schedule a call with us.