How to read a software proposal? As an agency owner, I'm exposing my own industry

Mehmet Bey wrote a nice list, but he missed my favorite item: "we'll look at it later."

Every "we'll look at it later" sentence said in a meeting averages out to three man-days. Nobody writes it down, nobody prices it, and then it pops up at delivery.

The suggestion is simple: at the end of the meeting, write down everything labeled "we'll look at it later" on a separate list and get that list signed too. Make sure it's written that it's out of scope. Since we started doing this, our delivery disputes have noticeably decreased.

Let me touch on the legal side; the following is general information, consult your advisor for your specific case.

In most cases, a proposal creates contractual obligations the moment it is accepted. So in projects started with the mindset of "we'll make a proper contract later," that proposal is the document looked at when a dispute arises.

Regarding intellectual property, the default rule is that copyright remains with the creator unless agreed otherwise. If you want the code to transfer to you, this must be explicitly written. The phrase "delivered" does not imply transfer of ownership.

Third point: third-party components. The licenses of the ready-made libraries used in the project also bind you. It's reasonable to ask for a list of the components to be used in the proposal.

Hi, I run a real estate office, I have no technical knowledge, can I ask a question?

The proposal I received mentions "responsive design" and "SEO-compatible infrastructure". Are these extra features, or things that should already be there? Also, do they affect the price? Thanks in advance.

Hakan Bey, both are standard by 2026, not separate features.

"Responsive" means it looks good on mobile (layout adjusts to screen width). Most visitors come from phones today, so it's a basic requirement, not an option.

"SEO-compatible infrastructure" is a very vague term. Concretely, it means: pages having their own title and meta description tags, readable URLs, fast page load times, and search engines being able to index the content. If these aren't listed individually in the proposal, make them write it out.

So if the price is increased specifically for these, object. Price increases for page count and custom functionalities.

One-sentence contribution from a freelancer: is the person writing the proposal the one who will do the work?

In agencies, the salesperson writes the proposal, the developer does the work. The gap in between is the mother of all delays. Question: "who made this estimate?" If it's the salesperson, multiply the timeline by 1.5.

I'm a project manager, here's what happened with us: we added a "change request process" section to the proposal.

It contains just one thing: for any out-of-scope request, a 1-page form, estimated time and cost, client approval. Sounds bureaucratic but the opposite happened, things sped up. Because now the "is this extra work or not" debate doesn't take an hour, you just fill out the form.

I'm an agency founder and I'll say the part that's against our interest, because honesty works in this thread.

Agencies giving low quotes usually aren't lying, they just don't see the whole picture. If you spend two days preparing a proposal, you get a realistic figure, if you spend two hours, you don't. Most proposals in the industry are prepared in two hours, because preparing a proposal is unpaid work and nobody wants to dedicate time to it.

The counterpart on the client side is this: the person who gets the cheapest quote usually gets the least thought-out proposal. The price difference comes back as extra work during the project and ends up costing more in total.

As a solution, we made the discovery phase separate and paid. A small fee, two weeks, at the end you get the real scope and real price. The client isn't obligated to continue with us after this stage, they can take the output and go elsewhere. Some did, no problem; we argued much less with those who stayed.

Let me write how it's done in practice. When making decisions, write down the worst-case scenario too, not just the best.

Let me summarize what's been said so far. Taking notes for two weeks yields better results than a six-month estimate.

When you try to change everything at once, nothing settles. Of course, it varies if your situation is different.

I went through the same thing.

Let me speak from the other side; I'm on the supplier side. If it's your first time, start small; scaling comes later.

Hope this helps.

There's a part I don't understand. Weekly written progress reports are much more useful than asking for dates.

That's all, sorry if I went on too long.

Noted, thanks.

Three different views emerged, they all complement each other. Processes without records never improve because you don't know what to fix.

Everything goes well for the first three months; problems arise in the fourth. If you have questions write them; I'll answer as best I can.

There's one point I'm curious about. Processes without records never improve, because you don't know what to fix.

Of course, it varies if your situation is different.

Don't miss this: Trying to do this alone is the most expensive way.

Good luck with that.

timely topic.

I have no experience with offer, so I'm asking. People defend habits not processes. Resistance comes from there.

Hope this helps.