You can't tell good code from bad code. That's the whole problem.
You've decided to build something — a website, an app, some internal software to stop running your business on spreadsheets. That part was the easy decision.
Now you have to pick who builds it. And unless you're technical yourself, you're being asked to judge people on a skill you don't have.
Anyone can show you a slick portfolio site and a confident pitch deck. You have no real way to check, on your own, whether their code is clean, whether their timelines are honest, or whether they'll still answer your calls three months after you've paid them.
That's not a knock on you. It's just the nature of hiring for expertise you don't personally hold — like picking a lawyer or a contractor. The good news is you don't need to learn to code to make a smart choice. You need to know what to look for, and what questions actually reveal something.
Why this decision matters more than the invoice
Say you hire a freelancer off a marketplace because their rate was half of everyone else's. Three weeks in, the check-ins get shorter. Then they stop entirely. You're left with a half-built app, no documentation, and someone else's code you now have to pay a stranger to untangle — assuming anyone will touch it at that price.
Or the opposite story: a slick agency oversold you in the pitch. Big promises, impressive case studies, a proposal full of buzzwords. Six months and a chunk of your budget later, you have a product that technically works but isn't what you asked for, built by a junior team you never actually met during the sales calls.
Both of these are common enough that if you ask around, you'll probably hear a version of one of them from someone you know.
The real cost isn't just the money you paid. It's the year you lose. Your competitors keep moving. Your own motivation takes a hit. And starting over with a new partner is slower than starting fresh, because now someone has to figure out what the last person did before they can fix it.
A technology partner isn't a vendor you transact with once. If the build goes well, this is a relationship that runs for years — updates, new features, fixing things that break, scaling up when business picks up. Pick badly and you're not just unhappy with one project. You're stuck either sticking with someone who isn't working out, or paying twice to switch.
What to actually evaluate
Past work in your actual situation
A beautiful portfolio doesn't tell you much on its own. What matters is whether they've built something with similar constraints to yours — same industry, similar scale, similar complexity.
A team that's built ten restaurant ordering systems will spot problems in your requirements that a generalist agency won't, because they've already hit those problems once. Ask for examples close to your use case, not just their best-looking work.
How they communicate before you've paid them anything
This is the part people skip, and it's probably the most useful signal you'll get.
How someone behaves during the sales process is close to a preview of how they'll behave once you're a paying client. If they're vague now, slow to respond now, or dodge direct questions now — that's not going to improve once the contract is signed. If anything, it gets worse, because now there's no more deal to close.
Pay attention to response times, whether they actually answer what you asked, and whether talking to them feels like a conversation or a sales script.
Whether they ask about your business, or just pitch features
A partner worth hiring will ask you things like: who are your actual users, what happens today without this software, what's the one thing that absolutely cannot break. A partner selling you a template will skip straight to talking about their tech stack and their timeline.
Good questions early on are a sign someone is thinking about your problem instead of their next invoice.
Ownership and IP terms, spelled out before you sign
Who owns the code when it's done? Who owns the design files, the source repository, the domain, the accounts? Is this written down, or verbal?
This sounds like a formality until it isn't. Businesses have been held hostage by their own developer over exactly this — the freelancer holds the credentials, the client has no leverage, and suddenly a "quick fix" costs a lot more than it should. Get this in writing before any money changes hands.
What happens after launch
Launch day is not the finish line. Bugs surface once real users touch the product. Servers need monitoring. Something will need tweaking within the first month, guaranteed.
Ask specifically what support looks like after launch — is it included, for how long, at what response time, and what counts as a "bug fix" versus a "new feature" they'll want to charge for separately.
Red flags vs. good signs
| Behavior | Red Flag | Good Sign |
|---|---|---|
| Scoping the project | Vague verbal estimate, "we'll figure it out as we go" | Detailed written proposal with phases, deliverables, and timelines |
| Early conversations | Jumps straight to pitching tech and pricing | Asks about your business, users, and constraints first |
| Communication during the project | Goes quiet after the deposit clears | Regular updates on a set schedule, even when there's nothing exciting to report |
| Ownership of code and IP | No written terms, or terms that keep them holding the keys | Clear agreement that you own the code, credentials, and assets on completion |
| Pricing | Suspiciously cheap with no explanation of what's excluded | Priced in line with the market, with scope and exclusions spelled out |
| References | Reluctant to share past client contacts | Offers references or lets you speak to a past client directly |
| Contracts | Pushes to start work before anything is signed | Insists on a signed agreement before work or payment starts |
| Post-launch support | No mention of it until you ask, then it's unclear | Support terms defined upfront — duration, response time, what's covered |
Questions to ask before signing with any technology partner
- Can you show me something you built for a business like mine, and can I talk to that client?
- Who exactly will be working on my project — the people I'm talking to now, or a different team?
- What happens if I need to pause or end the project halfway through? Do I keep what's been built so far?
- Who owns the source code, the design files, and the hosting accounts once the project is done?
- What's included in the price, and what counts as "out of scope" and billed separately?
- What does support look like after launch — is it included, for how long, and how fast do you respond to issues?
- How do you handle it when requirements change partway through the build?
- What's your process for keeping me updated — a set schedule, or only when I ask?
Red flags that should make you walk away
- They won't put scope, price, or timeline in writing before starting work
- They can't or won't share a reference from a past client
- They're evasive about who owns the code and credentials once the project ends
- Their quote is dramatically cheaper than everyone else's with no explanation why
- They want full payment upfront with no milestones tied to it
- They talk more about their tools and stack than about your business problem
- Communication is already slow or inconsistent before you've even signed anything
The best predictor of how a technology partner will treat you after the contract is signed is how they treated you while they were still trying to win your business.
Finding a partner you don't have to keep watching over your shoulder
None of this is complicated once you know what to look for. It just takes slowing down enough to check, instead of going with whoever pitched the hardest or quoted the lowest.
This is also the kind of relationship we try to build with the businesses we work with at Kakshlink Technology — clear scoping before anything starts, straightforward communication throughout, and no ambiguity about who owns what once the work is done. If you're evaluating partners right now, learn about Kakshlink Technology or get a free quote and see how the conversation goes.
Frequently asked questions
How much should I expect to pay for a custom website or app?
It depends heavily on scope, complexity, and the region you're hiring in, so there's no single number that means anything without context. What matters more is getting a detailed written quote that breaks down what's included, so you can actually compare it against other quotes instead of comparing bare totals.
Should I hire a freelancer or an agency?
Freelancers can be a good fit for smaller, well-defined projects and often cost less, but you're relying on one person's availability and no backup if they're unreachable. Agencies usually offer more continuity and a broader skill set, at a higher price. Either can work well — what matters more is the specific person or team's track record and communication, not which category they fall into.
What if I don't know exactly what I need built yet?
That's normal, and a good partner will help you get there rather than making you show up with a finished spec. Look for someone willing to spend time upfront on discovery and scoping — asking about your business and users — before jumping to a price or a timeline.
What should be in the contract before I pay anything?
At minimum: the scope of work, payment milestones tied to deliverables, who owns the code and assets on completion, timeline expectations, and what post-launch support is included. If any of these are missing or vague, ask for them to be added before you sign.