As my first freelance graphic design & programming job, (I'm 19) I agreed to develop a web application for a local insurance agent.

I've taken 4 months to complete the job, while I estimated 1-2 months, originally. Each month, I demonstrated my progress, but continued to estimate a soon finish each meeting, not foreseeing the many issues I would run into in the development process. The insurance agent has not expressed verbal displeasure with the time that the job has taken, but his responses are short and concise, and I am nervous as to how he feels about the length of time taken.

I'm not sure how I should handle the situation after taking so long to complete the work. This business owner is well known in my town and could potentially lead to much more business if he is pleased with my service.

I want to know how I should proceed in order to maintain professionalism and do my best to mend my errors and achieve a good review by this employer to any potential employers in the future.

Here are the details that I'm taking into account:

  • I explained that this was my first full-scale web application, and that I was unsure of the time frame. I estimated 1-2 months.

  • I calculated the application price based on the time that I estimated the job would take a more experienced developer, as to not charge him more due to my inexperience. I priced the work at half of the amount that I estimated other freelance developers would charge, coming out to be $2000 total, for the design and development of a Chrome-friendly front and back end web application.

  • I'm not charging for actual time spent (not even close), but on a predefined amount.

  • This agreement was made in good faith, with no contractual terms. The owner of the business knows my father, who introduced me to this development opportunity, so this was adequately safe.

  • I'm a pretty good designer, who pays extreme attention to innovative interface functionality, visual "perfection", and efficient code. In other words, the app is good. Really good. And I've agreed to update and maintain the app for free, with the exception that hosting be paid for.

  • I've offered a free additional feature, a messaging client, in order to (hopefully) maintain his complacency with my inexperience.

How I should proceed, as in, should I apologize for the delay, ignore it, etc? As is it is now, I may receive reputation-damaging review after 3-4 missed finish date estimates (I should have just left the finish date open, but I made a mistake and continued to estimate a finish date).

  • 4
  • 1
    *comments removed* Please remember what comments are for
    – jmac
    Jun 5, 2014 at 7:49
  • Side note: your client probably did not realize the implications of "Chrome-friendly" - this may come back to bite you when he realizes that IE doesn't work...
    – mmaclaurin
    Jun 5, 2014 at 23:17
  • 1
    This question doesn't appear to be about navigating the professional workplace. Instead, it sounds like a freelancing question. For future reference, we have a Freelancing SE site for freelance problems. Good luck and thanks for participating.
    – jmort253
    Jun 6, 2014 at 14:51
  • 1
    Hey @jt0dd, I considered it, but the 10 answers would drown out any chance of members of that fledgling community being able to contribute meaningfully, especially when faced with Wesley Long's +113 score. If we had put this on hold earlier, I'd probably consider migrating it. However, it should be safe as we generally don't delete positively scored posts, even if off-topic. If you do feel something is unanswered that would be better addressed there, you could re-ask on Freelancing SE, but just be sure to tailor the post to that community, no copy pasting please. :) Hope this helps!
    – jmort253
    Jun 26, 2014 at 4:14

10 Answers 10


Welcome to software development.

Rule 1: Clients never know what they want or need going into the project. If they did, they'd be project managers. They know how to do their jobs, not build the tools to do their jobs. In larger projects, there is a whole profession known as "Business Analysts" who figure that out for them.

Rule 2: Clients will create new requirements throughout the project, mainly due to Rule 1. That is why you want to have clearly defined and measurable requirements and deliverables in writing.

Rule 3: Those changing requirements are what make or break most projects. Make sure you have a clearly defined process for requirements changes, including adjusting price and the delivery schedule as a condition of accepting the change requests.

Rule 4: These issues are much more about project management than they are about your skill as a developer. You just got a lesson in what the difference is.

Rule 5: No one in their right minds expects a 19-year old to be able to manage a project, especially their first project, and get the time estimates right. The fact that it was only double your initial estimate is actually pretty impressive.

You said you completed the project as agreed without changing the price. That was the right decision. Chalk this one up to experience.

Tell the client, "I did a poor job of estimating the amount of labor in this project, but I believe I did a very good job on the actual product. I am not changing our agreed-upon price due to my mistake. I hope you are happy with your finished product, and I hope I can use you as a reference in the future."

As far as visual "perfection" - you need to decide with each project if this is a "portfolio" job or a "pay the bills" job. For instance: I started my career as an audio engineer. I did some work for free for some young bands that I'd be unashamed to submit to any record label. I did some paid work for car dealership ads that was pretty much "Put a lav mic on him and I'll run it through a compressor later" because I needed to finish the job and get paid that day. Sounds like you did a portfolio piece. If you can use it as such, then do so and be happy.

Remember -- your main goal is to get better. You're 19. You've got decades to get better at your work. Don't get discouraged.

  • *comments removed* Please remember what comments are for
    – jmac
    Jun 5, 2014 at 7:51
  • I was just impressed at how incredibly insightful this was, considering how concise it is. I think it should be required reading for any aspiring developer
    – fostandy
    Oct 30, 2018 at 2:19

Just added an account to give you my two cents. In short don't worry too much. Wesley Long has given you very good advice/reasons why the situation you find yourself in is absolutely acceptable.

I want to add another perspective to this: Don't sell yourself short!

If it takes you twice as long to complete, maybe you have created something of more value. It is impossible to judge precisely how much such a development is worth, especially by clients who don't know the technology behind what you are doing. They rely just as much on your presentation to judge the merit of the work as on their own past experience.

Your attitude in how you present the results matters! There is a lot of psychology involved in this too. A red flag for me was the promising of free additional features. All this achieves in my mind is reducing the value of your overall work.

I don't know your industry or what you specifically have done, but I have seen much greater projects offer far fewer results, others overrun by much greater multiples of the original estimate.

I am not advocating that you focus solely on the presentation and selling bit and neglect your actual cores skills, the world has enough of those people. Just remember that you will have to sell yourself constantly throughout your career. One part of that is producing state of the art product, the other is making your client realize that.


I have been in the same situation a few years back.

I estimated a project 3 months at about 25h/week and finished after 5 months at 35h/week on average.

Your decision was good. You shouldn't charge your client for your own mistake.

In addition, adding a few features for free to compensate is the right way of doing business.

Don't sell yourself cheap

But one thing you have to be careful with is being underpaid. The first big project you do is always difficult and thus being underpaid is not an issue. But 2000$ for 2 months of work doesn't seem really fair in the first place (though it depends how much time per week you planned to spend on it).

Estimating a project is tough work and it will come with time. Some say you need to multiply by Pi your estimate to actually have the right one as you will have many unexpected issues, some testing etc...

Don't do long term engagement for free

I think your only real mistake is the maintenance of the website for free. Maintenance is a full part of the business and engaging yourself to maintain it for free will probably become a bother later for you.

  • 5
    Re:Long term maintenance, I would view any offer of perpetually free updates and maintenance as a sign of inexperience, and wouldn't have a lot of confidence in such an offer.
    – stoj
    Jun 5, 2014 at 15:38

Actually your question pretty much answers itself. You already proceeded well:

  1. Delivered a high quality product
  2. Didn't charge anything for extra time spent
  3. Added an extra feature as a compensation

Since your client didn't express any displeasure, the odds are he thinks you handled it properly. Short and concise answers don't necessarily mean he's angry. It most probably means he has responsibilities, treat 3 dozen emails a day so he doesn't take the time to start his messages with "Hey man, how are you? Had a nice weekend?".

One last thing : Don't be too hard on yourself. Estimating workload on a project is a skill that can only be acquired with experience. It's not easy, and is pretty much a job in itself called project manager. You'll get better at it.


You already have chosen an answer, and some people vaguely touch on this, but what this boils down to is something really simple:

Irregardless of how simple or complex a project might be, you need to be in control of the structure of your project from the beginning.

The less you plan, the more you will fall into an endless development cycle. You need to set clear boundaries so the client gets what they want & you get what you want.

The reality is unless this person knows you, the chances of you getting out extra fees at this point are zero. That said, this could be a case where after this project is done you have a talking point of, “Well, that last project had issues. If you want to work with me on a new project, this is what we need to do.” Meaning leverage this failure towards future successes!

That said, it’s taken me decades to perfect how I handle these situations. But logically you yourself need to divide things up along these lines.

  1. What are your strengths. Don’t lie to yourself about this. I work mainly in the Unix/Linux systems administration worlds & I meet developers all the time who boast about how great they are at full-stack development. Baloney. Most web developers are good at front-end design, some more at front-end development, some more at backend development, others at DB structuring and some are good at systems administration. But you really cannot be a master of all those skills. The point being is if someone approaches you for a project, they will most likely want you to be all of the above plus a project manager. Are you ready to take that responsibility? From the outset you need to basically say, “Well, you saw I did X. And you think your project is X. But actually I am Y. I can help you, but you need to realize my strengths & limits.”
  2. Create paperwork before anything else: Map out the project into chunks. Bullet list points. For example, a web development project can be broken down into: discovery, information architecture, wireframes, visual design & functional design. Make it very clear that each bullet point is a separate thing. And be prepared to say things like, “We need to discuss that at a later stage, perhaps at this point…”
  3. Create a timeline. Typically in discovery you can estimate the overall timespan of a project including milestones & goals. Make it very clear to the client this will happen then, that will happen later. I personally like to make a week the minimal timespan for anything. So for simple fixes, 1-2 weeks. For a site redesign, 3-6 months.
  4. Factor in maintenance. Maintenance should always be a separate thing from you main project & negotiated as such. Do not let your primary development cycle ever bleed into maintenance of code.
  5. Exit strategy. Them most basic exist strategy is the classic 50/50 split. Meaning, once you are happy with each other & the goals, ask for 50% upfront. Make it clear that no work happens until that 50% is received. Also make it clear that if for any reason you feel you need to abandon the project, you keep the first 50% & do not receive the second 50%. This happens a lot more than you expect. And you should not be ashamed to say, “Look, this is not working out. I need to stop this.”
  6. Who gets custody of the children (aka: code): Also define what an exit might entail code-wise. Meaning do you keep half-baked code? Or do you give it to the client & say, “This is the work I have done so far. Pass this onto someone else.” This is a tough call. In general don’t feel proprietary towards contracted code.
  7. Have coding allies. This is another great thing to do. Basically, always network with other coders. And if you start getting tired of a project, don’t worry about asking one of these other coders to take over for you. That said, many coders don’t want to take over someone else’s headaches. But then again—looping back to strengths—for all you know another coder could have skills they are strong at that you are weak at. So you could form a team to compliment each other even just for one simple project.
  8. Do not take business personally. All of these above points are focused on making you realize you are entering a business transaction so you should not take any of these decisions personally. So if a client acts like a jerk & attempts to get more out of you than you agreed to? Just point it out to them. They don’t accept that? Walk away. And if you are upset? Guess what? We all get upset at botched projects. Take a walk around the block. Get it out of your system. But bounce back. People want you for your skills & you should treat your skills as a commodity.

Also, create realistic boundaries. I freelanced for 10+ years & whenever I mentioned that to people casually I would get every nutty idea anyone had thrown at me as if I was looking for work. In general society sees freelancers as charity cases. And the best thing I did to stop that endless stream of “great ideas” was to get a full-time gig. But if I go back to freelancing, my attitude is simply to say right at the start, “Look, I need to just say I’m not really looking for work right now.”


Good advice. Never tell client when final product will arrive. Instead of that, draw them a timeline how much time will every piece take. Divine your project to phases or modules and present every and each when it reaches stable state. Gather input for every stage and module and be honest towards client about additional costs. Be flexible. Your clients will also appreciate that, cause they want a tailored solution.

Also it's a good idea to give an estimate or base cost of a project at the beginning, but also inform them that additional features will cost extra and prolong project.

Such workflow will also give you more stable relation with clients and build more trust in your relations with them.


  • Thus, don't charge them for your own mistakes. That is very bad and will leave bad taste after you are finish.
  • Leave good documentation about your project. Both for clients and for future maintainers (most likely it will be you, so be good for yourself).
  • When you are leaving project you can suggest them what kind of improvements could also be applied to project. (be honest)

PS. For a 1st project, it's still ok to just double needed time. You will get better at estimating next projects, so keep up.


For a first project, I don't think you actually did that bad. It is hard to tell without knowing the persons involved, but if your client has not expressed displeasure, and it is likely that he is pleased with the end result, I think you can assume that he is happy.

As to how you should proceed, other answerers have given good advise on how to communicate with your client. What you should think about now, is how you can use these experiences in your next projects.

  • Make sure you and the client are on the same page as to what work is to be done - write a clear specification
  • Learn how to close a project - how to tell the client that your work is done, and if he wants something more, you're charging for it
  • Sometimes, you will have to put away some of your perfectionism. Yes, you've taken your time to write clean and efficient code, but does the client really care that much? If you're getting too much into detail, you're going to blow your estimates again
  • Don't ever offer perpetual, free maintenance - this can come back and bite you, if you and your client don't have a clear understanding of what's covered by 'maintenance'.
  • In the future, if you see that maintaining this first project takes too much time away from other work, don't be afraid to tell your client that you have to prioritize the other (paid) work.

Best of luck with your career!


The client hasn't said anything about the delay, quite possibly because the application is very good (if we take your word for it), the fixed price was a good deal, and the over-time was free.

If you're nervous about this (or anything else), a good strategy is for you to be the person to bring it up first.

"Although you seem satisfied with the project, and I also feel good about the quality, I regret that I didn't accurately predict the time it would take to complete. Software project estimation is widely understood to be tricky; I will work on improving this skill with each new work experience. I hope that the late delivery didn't negatively impact your business."

If you bring up anything first you always retain a better footing or even an upper hand. When the other party brings it up, there is often a lingering sense, whether only perceived or real, as if the issue were being introduced with, "you don't seem to place much importance or awareness on the following, but I'd like to talk about ...".

  • this doesn't seem to offer anything substantial over points made and explained in prior 5 answers
    – gnat
    Jun 5, 2014 at 21:25
  • @gnat offers less TL; DR.
    – Kaz
    Jun 5, 2014 at 22:56
  • I find it hard to figure how less/tldr is compliant with Back It Up and Don't Repeat Others rules
    – gnat
    Jun 6, 2014 at 6:30

IT projects are notoriously hard to estimate, just look at all the big public IT projects (especially UK) that have blown their schedule and budgets many times over.

  1. Try not to accept another fixed price project until you research "function points" (it's not a number of functions in your code...) and how to write job contracts based on function points.
  2. Since you're just starting out you will probably have to accept a few more fixed price projects. A rule of thumb that served me well for quick estimates: if you think it will take a set amount of time, double that and add another 10%. You will probably still underestimate but not as badly. Engineers tend to be too narrowly focused on how to solve the problem and always miss all the things that can go wrong, and fail to account for all ancillary bits and pieces that are also important part of the delivery (e.g. documentation, system set-up and configuration, testing, training...). Also, as already mentioned by other people, project is never clearly defined in the beginning regardless of how clear a vision your customer things he has. There are always piles of things that are not well defined and need further work to elaborate, and there are always additional features that client thinks of later and naturally assumes you will do for free under fixed price contract (refer back to point #1).
  3. Accept that you will lose money on these initial projects and just take them as a learning experience.
  4. Check up on contract law in jurisdictions where you do work. In some places if someone skilled in the relevant art is making an estimate, that estimate is not allowed to be more than 20-30% off the actual time/amount, even if additions to the contract were negotiated and added to the contract on request of the client. If these extras accumulate then you have to renegotiate and sign the whole contract from scratch or client will have the legal right refuse to pay anything above the initial sum + 30%.
  5. Make sure that you make regular DELIVERIES (not just show the client you progress) as if you have no accepted delivers past deadline, he may refuse to pay you anything.

And, as already mentioned in several other answers, this is REALLY bad:"And I've agreed to update and maintain the app for free, with the exception that hosting be paid for."

You should NEVER promise perpetual free, unlimited and UNDEFINED service to anyone. I hope you didn't put that in writing.


No need to "apologize". IMO that is decidedly unprofessional, unless your client explicitly pushes you up against the wall about it.

If that does comes to pass, don't try to squirm out of it, just apologize that you're still a beginner and tried your best, but you're not yet seasoned in making accurate time estimates. Don't get into long explanations and excuses. Be short, to the point, and professional.

Offering "extras" as compensation for the delay might not be such a good idea, as others have mentioned: That tends to cheapen you and makes you appear a bit desperate (never a good thing), puts focus on your lack of experience, and leaves you vulnerable to endless requests for "freebees", etc. But what's done is done. Avoid that in the future.

You didn't charge based on time, you were up front and honest with them from the beginning, and priced the work based on your experience. So, I think you are off to a good start. As long as you delivered a solid working product, I don't think you need be too concerned. The client may seem impatient, but if you did a good job they will soon be appeased when they enjoy the fruits of your labor.

For the future: Until you get really good at estimating your delivery times (that takes quite a while, and often even experts make mistakes on that) triple or quadruple (at least...) the number that first seems viable to you.