What to Expect When Working With a Developer (A Real Talk for Small Business Owners)

Let me guess how you got here. Your business has grown to the point where spreadsheets and off-the-shelf software aren't cutting it anymore. Maybe you need a customer portal so clients can access information without calling. Maybe you need a dashboard that actually shows you what's happening in your business instead of requiring three people and two days to pull a report. Maybe you just need something that works the way your business actually works, not the way some generic software thinks businesses should work.

So you're looking at hiring a developer, and it feels a bit like wandering into a foreign country where you don't speak the language. What should you expect to pay? How do you even evaluate if someone's any good? What questions should you ask? How do you communicate what you need when you're not sure yourself?

I've been on both sides of these conversations for over 15 years—working with everyone from solo entrepreneurs to companies with hundreds of employees. Let me share what actually happens in successful developer-business owner relationships, and what you should look for to make sure yours is one of them.

First, Let's Talk About What You're Actually Buying

When you hire a developer to build custom software for your business, you're not just buying someone to type code. You're buying someone to:

Understand Your Business Good developers spend a lot of time asking questions that might seem obvious to you. "Walk me through how you process an order from start to finish." "Who touches this information and why?" "What happens when this weird situation comes up?"

These questions aren't busywork—they're how developers figure out what you actually need versus what you think you need. I can't count how many times business owners have described what they want, and after I understood how their business actually works, we built something quite different that worked better.

Make Recommendations You Didn't Know to Ask For You might think you need Feature X, but an experienced developer might say, "Actually, based on what you've told me about your workflow, Feature Y would solve the same problem faster and cheaper."

Sometimes the best developer relationship is when someone pushes back a little—not to be difficult, but because they've seen this movie before and know how it ends.

Translate Between Business and Technology You speak in terms of customers, processes, and outcomes. Developers speak in terms of databases, APIs, and user interfaces. Good developers translate between these languages fluently. They explain technical trade-offs in business terms and understand business needs in technical terms.

Be Honest About What's Feasible Not everything is worth building. Sometimes the juice isn't worth the squeeze—what you're imagining would cost $50K and save 2 hours per week. A good developer will tell you that honestly, even though it means less work for them.

The Money Conversation Nobody Wants to Have (But We're Having It)

Let's just put the numbers out there because wondering about cost is probably keeping you up at night.

For Small Business Custom Software: A simple customer portal or internal dashboard: $15K-$40K A more complex system with multiple integrations: $40K-$75K A comprehensive platform with advanced features: $75K-$150K+

I know that probably made your stomach drop a bit. But here's the thing—you're not comparing this to zero dollars. You're comparing it to what you're currently spending on the problem.

If you're paying three employees to spend 10 hours a week doing something manually that software could do automatically, that's $45,000 a year at $75/hour. A $30K software solution that eliminates that work pays for itself in 8 months. Every year after that is pure profit.

Payment Usually Works Like This:

• 30% when we start (covers planning and early development)
• 40% at the halfway point (when core features are working)
• 30% when it launches (after final testing and deployment)

This structure protects both of us—you're not paying everything upfront and hoping for the best, and I'm not working for months before getting paid.

What the First Conversations Should Feel Like

When you're talking to a potential developer, you should leave the conversation feeling:

Heard, Not Sold To Good developers ask way more questions than they give answers initially. They want to understand your business, your challenges, and what success looks like before proposing solutions.

If someone's pitching you a specific solution in the first 15 minutes, they're not listening—they're selling. That's a red flag.

Educated, Not Confused Technical explanations should make sense, not make you feel dumb. When I explain why I'm recommending PostgreSQL over MongoDB, I say it in terms of your business needs, not developer jargon.

If you leave a conversation more confused than when you started, that's a communication problem that won't get better during the project.

Realistic, Not Magical Nobody can build your dream system in three weeks for $5,000. If someone's promising that, they're either lying or misunderstanding your needs.

Good developers give you realistic timelines and explain what's driving the cost. They help you understand trade-offs—"We could do it this simpler way in 6 weeks, or this more robust way in 10 weeks. Here's what you get for those extra 4 weeks."

The Questions You Should Ask (And What Good Answers Sound Like)

"Have you built something like this before?" Good answer: "I've built similar projects for type of business. Let me show you examples and explain how those relate to what you need." Bad answer: "I can build anything!" (Confidence without specifics is concerning.)

"How will we communicate during the project?" Good answer: "Weekly check-ins where I show you working features and get your feedback. Email for questions, phone if something urgent comes up. I'll send progress updates every few days." Bad answer: "However you want!" (Lack of structure means lack of process.)

"What happens if I don't like what you built?" Good answer: "We'll show you working versions throughout the project so you can course-correct early. If there's a fundamental misunderstanding, we'll figure out how to fix it. I want you to be happy with what you're paying for." Bad answer: "That won't happen." (Everyone is overly confident until reality hits.)

"What if you get hit by a bus?" (Less morbid version: "What if you're not available after launch?") Good answer: "All code is yours with documentation. I'm here for support, but you're not locked in. I can help you transition to someone else if needed." Bad answer: Discomfort or unwillingness to discuss this. (You don't want to be held hostage.)

What Your Part of the Partnership Looks Like

This is a partnership, which means you have responsibilities too. Here's what good developers need from you:

Quick Feedback When I show you a working version and ask "Does this match what you need?" responding in 24-48 hours keeps the project moving. Waiting a week means I'm juggling other projects and losing context.

You don't need to write novels—"Yes, that's right" or "Actually, let me explain this differently" is perfect.

Access to People Who Know the Details If I'm building software for your operations team, I need to talk to your operations team at some point. You can coordinate it, but I need access to the people who'll actually use this thing.

Honesty When You're Confused Please, please tell me when something doesn't make sense. "I'm not sure I understand why we're doing it this way" is the best thing you can say. It's not a dumb question—it's catching potential problems early.

Reasonable Availability I'm not expecting you to drop everything, but being available for weekly check-ins and responding to questions within a few days keeps things moving. If you disappear for three weeks, the project stalls.

Red Flags That Should Make You Walk Away

Requiring 100% Payment Upfront Never, ever do this. Legitimate developers don't need all the money before starting work. This is the #1 sign of someone who might disappear with your money.

No Examples of Previous Work Everyone starts somewhere, but if someone can't show you anything they've built, you're taking a big risk. At minimum, they should have personal projects or open source contributions.

Reluctance to Put Scope in Writing "We'll figure it out as we go" sounds flexible but creates endless scope creep. Clear written proposals protect both of you.

Overpromising on Timeline or Budget "Sure, we can build that in two weeks for $3,000" when you've gotten quotes of 8 weeks and $25K from others. Trust the consistent quotes, not the outlier.

Poor Communication Before the Project If someone takes three days to respond to emails during sales process, they'll be worse during the actual project. Communication doesn't improve—it gets worse under deadline pressure.

What Good Collaboration Actually Looks Like

Here's how a typical 8-week project usually goes:

Weeks 1-2: Planning and Design We talk through your needs in detail, sketch out how it should work, make decisions about what to build first, create designs so you can see what it'll look like, and establish the weekly check-in schedule.

You'll see mockups and wireframes. They're not pretty—they're functional outlines. This is when it's easiest to change direction if we misunderstood something.

Weeks 3-6: Development I'm building working features every week, showing you progress in weekly demos, adjusting based on your feedback, and sending quick updates between meetings.

You'll see rough versions that work but aren't polished. That's normal—we refine later. What matters is "Does this do what you need?"

Weeks 7-8: Final Polish and Launch Making it pretty and smooth, fixing bugs, testing with real data, training your team, and launching to actual use.

This is when we work out the rough edges you couldn't see until using it for real.

After Launch: Support and Evolution Every project needs a few tweaks after launch when real users find things we didn't anticipate. This is normal, not failure. Good developers expect it and budget time for post-launch support.

The Long-Term Relationship Most People Don't Talk About

Here's something most business owners don't realize: the first project is usually the beginning of a long-term relationship, not a one-time transaction.

Your needs will evolve. You'll want to add features. Integrations will change. Business processes will shift. Three months after launch, you'll think of something you wish it did.

Having a developer who already knows your system, your business, and how you communicate is incredibly valuable. Many of my client relationships span years—we build the initial system, then I'm available for enhancements and support as needed.

This is good for both of us. I know your business deeply, you're not explaining everything to someone new, and improvements happen way faster because I already understand the context.

Making Your Decision

Choosing a developer isn't just about technical skills—it's about finding someone you can work with comfortably, who communicates clearly, who understands your business, and who you trust to spend your money wisely.

You should feel like they're on your team, not just a vendor. The best projects feel collaborative, where both of us are working toward the same goal of making your business better.

Let's Have an Honest Conversation

If you're considering custom software for your business and this approach resonates with you, let's talk. I promise:

• No technical jargon you can't understand
• Honest assessment of whether custom software makes sense for you
• Straight talk about timeline and budget
• Clear explanation of what you'd be getting

Schedule a consultation and we'll have a real conversation about your business, what you're trying to accomplish, and whether I can help. If I'm not the right fit, I'll tell you that too—and maybe point you toward someone who is.

No pressure, no sales pitch. Just a conversation between one business owner and another about solving real business problems with technology.