A Small Time Tracking Mistake That Taught Me a Big Freelancing Lesson

By Salomon Mwilo

Sometimes the most valuable freelancing lessons don’t come from our successes, they come from our mistakes. This is one of those lessons, and I hope it helps other freelancers avoid making the same one.

Last week, I completed approximately 35 hours of work across two Upwork contracts using manual time tracking. Like many freelancers, I had developed the habit of recording all of my hours at the end of the week instead of entering them as I worked.

My plan was simple: submit all of my hours on Sunday evening before the weekly deadline.

Unfortunately, my internet connection failed on Sunday and wasn’t restored until Monday afternoon. By then, the Upwork work week had already closed, and I could no longer submit my manual hours.

At first, I thought the internet outage was the problem.

After discussing the situation with my clients, I realized the outage wasn’t the real cause at all.

The outage simply exposed a weakness in my workflow.

The real mistake was waiting until the end of the week to record my time.

Had I entered my hours every day, or even after each work session, the internet outage would have been little more than an inconvenience.

Transparency Matters

Rather than looking for excuses, I decided to be completely transparent with my clients.

I explained exactly what had happened, provided a detailed breakdown of the work I had completed each day, and accepted responsibility for my mistake.

That conversation turned into something much more valuable than simply solving a payment issue.

It became a lesson about professionalism.

What I Learned from the Client’s Perspective

Michael shared two observations that changed the way I think about time tracking.

First, recording your hours while the work is still fresh in your mind makes your timesheet much more accurate. You’re able to remember exactly what you worked on and provide meaningful notes instead of trying to reconstruct an entire week from memory.

Second, clients also depend on timely reporting. Recording hours throughout the week gives them time to prepare payments, manage cash flow, and avoid unexpected Monday morning surprises. Before this experience, I had only considered time tracking from the freelancer’s perspective. I hadn’t realized how much clients also rely on good reporting habits.

Those two ideas helped me understand that time tracking is not just an administrative task, it’s part of building trust.

Improving the Process

One thing I appreciate about working with good mentors is that mistakes become opportunities to improve the process rather than reasons to assign blame.

This experience encouraged me to rethink my workflow.

From now on, whenever I begin working, I record my start time. When I finish or pause, I record my end time and write a brief description of what I accomplished. I then enter my time into the Upwork Work Diary the same day instead of waiting until the end of the week.

It’s a small change, but it removes unnecessary risk and makes my records much more accurate.

Final Thoughts

Freelancing is about much more than delivering quality work.

Professionalism is built through reliable systems, consistent habits, and taking responsibility when things go wrong.

Technical skills help us win projects.

Professional habits help us keep them.

If this experience encourages even one freelancer to begin tracking their hours daily instead of weekly, then sharing my mistake will have been worthwhile.

Lesson learned

Don’t wait until the end of the week to record your hours. A five-minute habit each day can protect an entire week’s work and strengthen the trust between you and your clients.

Post 8: Cohort 1 wrapping up their demo and cohort 2 is being organized.

Cohort 1 is finishing up their demo project this next week. You can see the results posted on their Cohort-1 page. Also on that page is a short profile for each of them. Finally there is a short video interview of Efatha regarding his experience. The video was shot and produced by Théophile who is one of the candidates for Cohort-2. He did an excellent job, and Efatha showed his enthusiasm and eagerness as always. This will I hope, be an encouragement to the next students. Please check it out.

Once they complete their demo they need to plan what they will do next. Perhaps they will take on an independent project with a new Upwork client. Stay tuned…

Meanwhile I am beginning to kick off Cohort-2 with four guys that are new to web design and Upwork. First I have to write an Upwork job and invite them to join. Once they have made their decision, I will create a new Cohort-2 page where I will introduce them and describe what they will be doing.

One of my hopes is that the Cohort-1 guys will spend part of their time coming along side the new cohort and encourage, advise, and review the work of the new team. Their effort will be very beneficial both as a model of what success looks like and also as a practical guide and encouragement to keep going. Eventually, I hope that as the more experienced team takes on new projects they will invite the new guys to join them on some collaborative projects. That is really the best (only?) way to learn to be a professional developer.

As always, I ask that you please take a short minute to leave a comment below and let me know what you think.

Post 5: The cohort #1 team is busy!

My last post announced that cohort #1 was beginning their first project together.

I am very pleased to tell you that they are hard at work and making good progress. There are in fact two efforts underway:

  • Working together to build a working site using their collective skills.
  • More importantly, they are learning and practicing the skills described in our ‘Working in a team‘ page.

Philemon is the team leader on this project. He is wearing several hats and juggling those hats effectively. He is scheduling weekly team meetings where they review the work done in the previous week and planning and initiating the new work to be done. Meanwhile, he monitors the work of Efatha as together they are working on the primary web page for the new site. Efatha is doing the HTML and CSS work to build the look and feel of the front end of the survey application. At the same time, Philemon is coding the JavaScript code to read in the actual survey questions and to write the survey answers to data storage. They are collaborating on the same program day by day using their own unique skills. As they do so, they are doing code reviews of each other’s new code so that they understand how the pieces fit together and to make sure that the result meets the requirements.

Meanwhile, I (Michael) am monitoring their code commits and reviewing their code. I also have a cloned copy of the project repository on my development machine here in Texas. My contribution to the project is to manually test the working program as the end user (whose name is Fred) would. Not only do I use it in my browser, but I also have my clone of the repository inside a working full stack server. So, I am testing it as it will be fully deployed for the world to see and use. I am also using a testing framework called Selenium to automate the manual tests that I do. As I manually do the testing, Selenium captures all of my actions (click here, type there, scroll to somewhere else, …) and the results of my actions. After my test run, the captured actions are stored in a “test case” in the team’s testing library. Those test cases (and results) become part of the project repository that we all share. When Efatha and Philemon are working on a new feature or fixing a bug, they will be able to push a button and watch all of my testing get replayed against their new code. This way, they can quickly re-run all of my testing to make sure they have not broken anything. This shows the two processes of Integration Testing, and Test Automation.

Finally, Ash is busy on the deployment (full stack) work that will become the live demonstration of this whole project. Once that is deployed, he will be able to begin his own development task of collecting the survey results from the json data file that is written by the front end application and permanently storing the results in an SQL database in the deployed stack.

Once Ash has the demo site deployed, that deployment will run out of a live clone of the GitHub repository. Every day, that clone will pull the latest copy of the repository and the live site will reflect the previous days work by each member of the team. This is two processes called called Software deployment and continuous integration.

The real message of this post is a lot of knowledge, hard work done collaboratively across the globe, and in the first week of the project the team is already using most of the software engineering team processes described in our Working in a team page.

I’m writing this post on Friday of the first full week of the project. When the team meets (virtually) early next week, Efatha and Philemon will do a live virtual demonstration of the current state of the program. The whole team will be able to see real running code taking its first baby steps. This will allow us to ask questions, discuss options and next steps, and more importantly get a very tangible reward of their first week of working globally as a team.

Way to go team!

If you read this post, please leave a comment here so we may know your personal take away from this team’s efforts.

Post 4: A Big Celebration!

Today is a big day in the history of this effort for several reasons!

Our first cohort #1 has now finished the introductory challenges and are ready to work as a team.

Meet Philémon , Destin , and Efatha .

Two of our members have also finished projects that are important contributions to this site.

Philémon made major updates to the front-end web page, while Destin made major additions to our full stack page. Each of them successfully planned their project and executed it on time and according to budget. I was somewhat surprised that they each made good estimates and worked accordingly. They have learned a lot about agile methods without knowing what agile methods are. Good job guys!

Together the three of them are now embarking on their very own self managed team project.

With Philémon as team lead, the three of them are currently in the kickoff phase of their very own project. When they are well underway we will announce the GitHub repository where you can see their work as it progresses. There will also be a public demo site that you can see it in action. Stay tuned… When complete, it will likely be incorporated as a new feature of this mentoring site satisfying an outstanding enhancement issue.

They are currently getting oriented to their new project and are in a one week training iteration in order to begin to learn the important Agile development methods they will need to succeed. Some new additions to this site are featured on the Home page, and a new How to… page How To Do Easy Time Estimates. You will be able to spot those new sections by the marker graphic

The other part of their training is getting oriented to the use of a common Github repository that they each will clone and work on. Each will have separate “Issues” managed in the central repository. They will plan those issues as a team in weekly scrum meetings, and then each of them will decompose those larger “story” issues into smaller “task” issues. As each task is completed they will commit the code, test cases, and documentation to the main branch and then push it to the common repository. There the whole team will be able to review and guide each other’s efforts to make maximum use of the skills of all.

Please! If you read this post, leave a comment to let us know and congratulate our new team.