Questions, answered properly

A single-page website starts at $600. Most small business sites land between $1,400 and $3,000. Web applications start at $8,000, desktop apps at $12,000, and game prototypes at $10,000.

Those are build costs. Hosting and a domain are separate and ongoing, usually somewhere between $220 and $500 a year depending on the plan. On a small site that adds up to more than the build over three years, which is why I quote both.

There is an estimator on this site that prices it properly, including what the plan renews at.

Every project gets a fixed written quote before work begins, and that number does not move.

It does not. Scope is fixed in writing before work starts and that price holds.

Work you add outside the agreed scope gets quoted separately for approval. Work I underestimated is my cost to absorb. An estimate I got wrong is not an invoice you should receive.

One honest exception. Projects occasionally uncover something unknowable at the start, usually a third-party system that does not behave the way its documentation claims. You hear about that the week I find it, with options and prices, while there is still room to decide. Never at the end.

A deposit begins the work. After that, payments attach to delivered milestones rather than calendar dates. Each one falls due when something working exists and you have reviewed it. Smaller projects usually split in two.

No billing for calls or emails. No maintenance contract stapled to a build. No annual lock-in. A payment schedule tied to time rather than delivered work is worth questioning anywhere you see it, including here.

You do, entirely, starting on day one.

Source code lives in a repository you own. Hosting, domains, and third-party services are registered in your name with your billing details. On delivery you get full credentials plus documentation written for whoever maintains this next.

Check this with anyone you hire. A real share of this industry runs the opposite model: code held on the developer's account, hosting resold at a markup, the domain quietly registered to them. None of it is illegal. It is leverage, and it exists so that leaving hurts.

You should be able to fire me on Tuesday and hand everything to another developer on Wednesday. When that is difficult, someone arranged it that way on purpose.

Landing page: 1 to 2 weeks. Marketing website: 2 to 4 weeks. Web application: 6 to 16 weeks. Mobile app: 8 to 20 weeks. Game prototype: 8 to 30 weeks.

Now the part usually left out. On nearly every late project I have seen, development speed was not the bottleneck. Waiting was. Waiting on feedback, on copy, on logo files, on an internal approval, on a vendor who does not answer email.

I plan around that and tell you exactly what I need and when. The highest-leverage thing you control on timeline is replying within two days.

Yes, as a tool, alongside the languages I learned the long way. Most of this industry does now, and anyone telling you otherwise in 2026 is either behind or not being straight with you.

I have written HTML, CSS and JavaScript since I was 12. Those are old languages at this point. I know the code as well as I need to know it to ship in the modern age, and I use current tools to get there. I would rather tell you that plainly than have you wonder about it.

Here is the part that actually matters. What you are hiring is judgment about what is worth building, the discipline to finish it, and someone who answers for the result afterwards. Tools do not supply any of those.

You do not have to take that on faith either. My own projects are on the Work page, and they are built so the logic runs and tests without a screen attached. Determinism enforced by the build rather than by good intentions. That structure is what decides whether software holds up a year later, and it is not something a tool does for you.

Defects present at delivery get fixed free. Every project includes a warranty period covering faults in what I built. Charging you to repair my own mistake is not a business model I will run.

Separate from that: new features, changes to agreed behaviour, and breakage caused by a third-party service changing on its own are new work, quoted and approved before it starts.

Ongoing support is available month to month, and it is never required. If the software needs constant paid attention just to keep running, I built it badly.

Often yes, and it is more common than people expect.

It starts with a paid code audit, usually a few hundred dollars. I review what exists and write up the condition of the codebase, the risks it carries, and the realistic cost of continuing versus rebuilding.

Sometimes rebuilding is cheaper than untangling. That sounds exactly like what a developer would say to win a bigger job, which is why the audit is a document with visible reasoning you can take to someone else for a second opinion. It has value even if you never hire me.

The real advantage is that nothing is relayed. On a typical agency project, information travels from you to a salesperson to a project manager to a developer and back, losing detail at every hop. Here, the person who hears the requirement writes the code. Decisions that would take a week of meetings take one message.

Lower overhead also means equal seniority costs less, and you know exactly whose hands are on the work, which you often do not with a larger shop.

The tradeoffs. My capacity is limited, so I am not always free immediately. My bus factor is one, which is why everything lives in your accounts and is documented for a stranger. And I am the wrong hire when a project needs five specialists at once. When that is the situation I will tell you and point you toward a team.

I built my first websites at 12, for my parents' small businesses. I studied at Iowa State University and did UI/UX work for the Iowa DOT in Ames. Then I spent about two years at GoDaddy and about two years at Wix before going freelance.

That matters for one reason. When I tell you how this industry works, it is not a guess. I have seen how small business websites get sold and supported from inside the two largest platforms on earth, and I know where those products genuinely serve you and where they quietly do not.

It is also why I will tell you to use a platform when a platform is the right answer. I am not threatened by that recommendation. I helped build the thing.

Cedar Rapids, Iowa. Central time.

Most of the work happens remotely, which suits the majority of projects perfectly well. If you are in the Cedar Rapids or Iowa City corridor, meeting in person is easy and usually worth doing once at the start, because an hour in a room tends to surface things that a month of email does not.

Working with clients in other timezones is fine. I will tell you upfront if the gap is wide enough to slow a project down.

A well-built site removes every technical obstacle to ranking. Fast page speed, clean semantic HTML, correct metadata, structured data, valid sitemaps, real mobile performance. All standard in my builds, none of it an upsell.

That is necessary and not sufficient. Rankings also come from publishing useful content over time and from other sites linking to you. That is ongoing marketing work, mostly outside a build.

I will not guarantee a position. Anyone promising the top spot on a competitive term is either lying or does not understand the mechanism. What I will do is build the technical foundation properly so your content work pays off, and tell you which keywords are winnable versus which are owned by companies with a hundred times your budget.

Mostly TypeScript across the stack. React and Astro on the front end, Node and Postgres behind it, React Native for mobile, Unity or Godot for games.

The more useful answer is how the choice gets made. Two rules. It has to fit the problem, and it has to be maintainable by a developer who is not me. The second rule quietly disqualifies a lot of exciting technology.

Choosing tools because they interest the developer is one of the most common and least discussed ways clients get hurt. You end up with working software nobody else will touch. If a boring, well-documented, ten-year-old tool solves your problem, that is what you are getting.

Because they are rarely quotes for the same project.

Send one brief to three developers and you get $3,000, $12,000, and $40,000. The instinct is to assume the expensive one is greedy or the cheap one is a genius. Usually neither. What differs is the silent exclusions: testing, error handling, security, edge cases, deployment, documentation, handover.

The $3,000 version often exists. It works when everything goes right, on the developer's laptop, with one user. The distance between that and software surviving real customers is where the other $9,000 went.

How to compare bids properly. Ask each one to write down what is explicitly not included. Strong developers produce a long list. Anyone answering "everything is included" has not thought it through, and you will find the exclusions later at their hourly rate.

An existing tool is usually the better answer, and I will say so on the first call.

If Airtable, Shopify, Notion, or a subscription SaaS covers eighty percent of the requirement, buy it. You get it today instead of in three months, somebody else maintains it, and you can leave when it stops fitting.

Custom software earns its cost when the tool cannot bend to a process central to how you compete, per-seat licensing now exceeds the cost of building, staff manually move data between four systems, or the software itself is the product you plan to sell.

Recommending a competitor costs me a sale and buys a reputation. Most of my work arrives by referral, so that trade pays.

It depends on the project, so here is the comparison including where I lose.

Agencies justify the premium when you need several specialists at once, guaranteed continuity if someone quits, and a contract procurement will accept. The tradeoff is overhead, plus the senior person who sold the project frequently is not the one building it. Ask who writes the code and ask to meet them.

A senior freelance developer costs less for equal seniority, and you speak directly to whoever builds it, so nothing is lost in relay. The tradeoffs are real. My capacity is limited, my bus factor is one, and I am the wrong hire for work needing five people in parallel.

Offshore teams deliver strong value when you can write clear specifications and technically review what comes back. Without those skills the savings disappear into rework. That is a question about your capability, not their quality.