What Warning Signs Suggest a Developer Might Abandon the Project?

Based on patterns from real Pantip threads referenced in this article, recurring warning signs are: scope discussions and deposit conversations that were vague from the very start; the scope growing without any revision to price or timeline; updates during key delivery periods that consist only of 'almost done' with no verifiable deliverable; and response times that get progressively longer without explanation. No single sign is definitive, but multiple signs appearing together warrant serious attention.

I Hired Without a Formal Contract. What Evidence Can I Still Keep?

Emails where scope was discussed, LINE chat transcripts, any written quote or proposal, and bank transfer receipts for each payment instalment. These are the materials that thread authors in the article actually had when they needed to document what happened. Their legal weight depends on what a lawyer assesses in your specific situation — keep copies somewhere only you can access, not only on the developer's system.

How Large Should the First Deposit Be?

There is no fixed percentage that works for every situation. What experienced Pantip users recommend is tying each payment instalment to a specific, visible, verifiable deliverable rather than to a calendar date or percentage of time elapsed. The first deposit should be modest enough that if the project stopped immediately, you would not have paid for work that does not yet exist.

If the Developer Disappeared Halfway Through, Can I Hire Someone New to Finish It?

Yes, if you have access to the source code and whatever documentation exists. If the only copy of the unfinished work is on the developer's machine and you have nothing else, the realistic chance of a new team continuing without restarting is very low. This is exactly why the article emphasises asking for source code handover rights and clear access agreements before any project begins, not as an afterthought.

Who Should Own the Domain and Source Code While the Project Is Still in Progress?

Ask in writing before the project starts: who registers the domain and holds the account password, and at what point the source code is handed over to the client. This question applies to every vendor, including TumWebSME. A vendor who gives a clear, written answer to both questions is significantly less risky than one who avoids or delays the conversation.

If I Hire TumWebSME, How Can I Be Sure I Won’t End Up in One of Those Pantip Situations?

We deliver 100% of the source code to the client — you own every line. Payment is split across actual completed deliverables per the agreed SRS, not by calendar schedule. A 3-month free bug fix period is included after delivery. We are also happy to answer the three key questions from this article — about code ownership, domain access, and payment structure — directly and in writing at the first meeting.

When Your Developer Takes the Deposit and Disappears: Lessons from 7 Real Pantip Threads and How to Protect Yourself Before Paying

Imagine a small restaurant owner who decided to expand the kitchen at the back of their shop. They hired a contractor recommended by someone they knew, agreed to everything verbally, and paid a deposit. The contractor knocked down the old wall, poured half the new floor, and then simply disappeared. Calls went unanswered. Messages went unread. The owner eventually had to find a new contractor to come assess the site. The good news was that the new contractor said it was manageable — the poured floor could be worked with, just a few sections needed to be redone where the work wasn't up to standard, and from there they could carry on to completion.

This story isn't meant to make you afraid of contractors. I just want to point out one key difference between construction work and web or system development. With construction, even if the contractor walks off the job halfway through, what's been done is still there to see and touch — you can tell with your own eyes what's usable and what needs to be torn out. Code isn't like that. You can't see it. A business owner who was abandoned by a developer wrote on the Pantip forum that the work they'd paid for was completely useless. They ended the post with a sentence I think captures the heart of the whole issue:

No one else can pick it up and continue — it has to be thrown away entirely. (With a construction project, at least there's something to salvage...)

(Source: Pantip thread — "I hired a programmer to write software. Now he's abandoned the job. What can I do?")

In this article, I want to walk through six more threads just like this one — real accounts from Thai business owners who hired someone to build a website or system and had the work stop dead in the middle. I want to see what patterns repeat, and what a client can put in place before making their first payment to anyone — including us.

Check These Three Things Before Sending Any Payment

Before getting into the threads, here are three questions to ask anyone you're about to hire. They're not complicated. But the people who can't answer them clearly upfront are usually the ones who are hardest to chase down later.

Do they have live, working examples of past projects you can actually visit? And do they have a written contract or quote that spells out the scope of work?
Are payments broken into milestones tied to verifiable progress?
If they disappear mid-project, is there someone who can take over? And would you have access to your own data, code, and domain?

If any of those three can't be answered clearly, that's already a warning sign — whether you're hiring a freelancer, a small agency, a large agency, or us.

The Pattern That Repeats Across Seven Pantip Threads

I read seven Pantip threads in which Thai business owners described hiring someone to build a website or system and running into serious problems. The oldest thread in this group dates back to a contract signed in February 2015. Newer threads are still talking about the same issues. This is a pattern that has been repeating for years.

Stopping When the Work Gets More Complex Than Discussed

One trading business owner wanted to move from tracking orders in Excel and on paper to a web-based system that stored data in the cloud. They hired a programmer they knew through the shop. The work was slow from the start — it took over a year to get to something usable. Along the way, the programmer explained that their team had quit on the project, so they ended up doing everything alone. By the time the system was 80–90% done, bugs started appearing, and working solo meant the pace slowed further. The question they posted was exactly the kind that should have been asked on day one:

Can the data and code be extracted from the system we're currently using? Can we keep the domain, transfer it, or do anything like that? (Source: Pantip thread — "I hired a programmer to build a system, paid in full, now I can barely chase them for updates. I want to cry.")

This case never reached full abandonment, but the questions being asked were ones that should have been answered from the very start.

Another thread, described by its author as a follow-up to a previous one, involved hiring a programmer for a project agreed to take two weeks. By the deadline, it had stretched to nearly two months. Excuses included flooding at home and a broken computer. The owner gave more time. Then the programmer went completely dark. The thread author described it as disappearing silently, not reading LINE messages, not answering calls — like being kidnapped. They had to track down where the programmer worked full-time and call there directly before getting any response. (Source: Pantip thread — "Hired a programmer for 2 weeks, 2 months later still not done.") Reading it now might seem darkly comic, but for the person who actually had to do the tracking, there was nothing funny about it.

What Gets Lost Along the Way

Another thread involved hiring a freelancer for a system with a verbal agreement that revisions were unlimited. The full 100% was paid. But the remaining 5–10% needed to complete the system never got done. The freelancer argued that the design had kept changing, causing scope to balloon. The thread author wrote that it felt like the freelancer was abandoning the job but not quite — (Source: Pantip thread — "Hired a freelancer to develop a system, now they've abandoned it.") That state of limbo is more frustrating than a clean abandonment, because there's no clear point where it's over.

Another case had a proper written contract, a delivery date specified as late 2019 by the thread author as 45 days, with a penalty for delay written clearly into the contract at 3% of the contract value per day. And the work still slipped more than two months past the deadline. The thread author tallied it: 50% of the money paid out, roughly 30% of the work delivered. (Source: Pantip thread — "Freelancer abandoned the job. How do I sue for damages?") This case is notable because even with a real contract and a written penalty clause, the work still ran late. What the contract did provide was the ability to name the damages clearly: how much paid, how much received.

Another thread involved hiring someone to customize Odoo for ฿30,000, with a 60-day timeline starting February 2015. By late August of the same year, the programmer claimed the work was 90% done — but what had actually been delivered was far from what was agreed: features that hadn't been customized and screens that still hadn't been translated to Thai as requested. The thread author wrote that they had to initiate every single update request themselves — any problems never got communicated proactively. (Source: Pantip thread — "I hired an irresponsible programmer.") This case cost more than just the deposit: it cost seven full months that the business spent waiting for a new system with nothing to replace the old one.

Even Companies with Contracts Need to Check the Milestones

One thread author had been abandoned twice in a row. The first time, they hired two freelancers to build a car rental system for ฿90,000, with a ฿15,000 deposit and a one-month timeline. The freelancers disappeared, taking the deposit with them. The second time, they switched to hiring a company — a clear formal contract, ฿150,000 price, four-month timeline, 35% deposit. Delivery came and went with no meaningful progress. (Source: Pantip thread — "Advice on finding someone to build a web application.") This case shows that having a contract isn't enough on its own, if that contract doesn't tie payment to real, verifiable milestones.

Someone replying in that thread offered a technical suggestion worth noting: they recommended splitting the contract into three parts — a project management contract, a frontend contract, and a backend contract — so you're not depending on a single person for everything. Before hiring, they also suggested asking whether the person practices CI/CD as a way to identify people who work in a structured, systematic way. (You don't need to know what that term means in detail — it's just one question you can use to check. Not using it doesn't automatically mean someone does bad work.) On deposits, the same commenter offered a rough structure as a guideline: something like 15-30-65 paid across milestones. That's one person's advice in one thread — not an industry standard — but the underlying principle applies to any team you hire.

Most Freelancers Are Not Like This

I want to say this clearly. These seven threads don't mean hiring a freelancer is riskier than hiring a company. Most freelancers who take on a project see it through to completion. Many Thai businesses have grown because they hired skilled freelancers from the start. The threads above include both freelancers and companies with clear contracts where the work still ran late.

What caused each case to go wrong tends to be specific circumstances more than the person themselves. In one case, the supporting team left the project partway through and they had to go solo. In another, the design kept changing without any adjustment to price or timeline for the added work. In another, a single person took on more than they could handle alone. If you want a more detailed comparison between hiring a freelancer versus a company with a team behind them, I've written about it at Freelancer vs. Web Agency: Which Is Right for Your Business?

Even the most frustrated thread authors in these seven cases didn't close the door on freelancers as a whole. The author of the Odoo customization thread ended their post by writing: anyone who wants to take on the job, feel free to contact me. They were angry that the work wasn't finished — not angry at the entire profession.

Three Things to Know Before Paying the First Installment

Beyond milestone payments, two more things need to be clearly answered before you sign anything: who the website domain is registered under, and where the source code lives while the project is still in progress. These sound like small details but they tell you everything about whether you can keep moving forward if the other party disappears — or whether you'd have to start over from zero. If you want a more complete checklist before choosing any vendor, I've put one together at How to Choose a Web Development Company: 7 Things to Check Before Hiring

If Something Goes Wrong: What People in These Threads Did

I need to be upfront first: we're a web team, not a law firm. What follows isn't legal advice — it's what the thread authors described doing or planning to do.

The first thread author asked in their post where to file a police report, whether the police would accept it, and noted the evidence they had: email correspondence, a pricing document, and transfer receipts for each installment. The thread author with a written contract and a penalty clause planned to sue for damages, claim the penalty per the contract, and asked whether fraud charges were possible. The Odoo customization thread author wrote that they expected to send a cancellation notice by the end of that month — a lighter outcome than the other two.

What all three shared was the evidence they had held onto: emails, chats, transfer slips, and the contracts themselves. That documentation was what gave them options when they had to decide how to proceed. Without it, those options would have been far more limited.

If You Hire Us: How These Three Points Apply

This article wouldn't be complete if I only spoke about what to check with everyone else and said nothing about ourselves. So I want to be direct about how we answer the three questions from the opening of this article.

Every line of source code belongs to the client — 100%. It's all delivered at the end of the project. If you want a different team to maintain or develop it further in the future, you can. There's no lock-in that requires coming back to us. Payment is split into milestone-based installments tied to verifiable progress. Each installment has a scope document (the SRS) that defines what needs to be delivered before that payment is due. You pay when the work in that phase has been built and delivered as agreed in the contract. After delivery, there's a three-month free bug-fix warranty. Ongoing maintenance after that can be arranged as a separate contract — it's not mandatory.

On domain ownership: our packages include a complimentary domain registration in the early stages of every project. But I want to be honest about this — who the domain is actually registered under is a question that should be asked and answered clearly in writing with any vendor, including us. Don't let it slide because you feel awkward asking, or because you want to move quickly. Asking at the point of signing is always easier than asking when you want to change providers later.

Our starting prices are ฿79,000 for a website and ฿249,000 for a custom-built system. The scope agreed on is written into a document before work begins. Anything outside that scope is discussed separately as its own matter. Those figures are the publicly listed prices on our package page. When you request an actual quote, confirm tax terms with the team. If you'd like to see how website pricing in the market is generally determined, I've written about it at Website Development Cost in 2026: Factors That Determine Value

If you're starting to evaluate which package to begin your business website from, all the details are on our website packages page.

Why Checking Early Is Worth More Than Fixing It Later

The Odoo customization thread author spent seven months before realizing what they'd received wasn't what they'd specified. The trading business owner who hired someone to build a stock system spent about a year getting to something usable — and still had to think about data extraction and domain transfer once the system was running. Asking these questions at the point of signing takes under an hour. Finding out later that they can't be answered means months or years of a business waiting for a new system with nothing replacing the old one. The more your business depends on that system, the more expensive it becomes to not have asked these questions from the start.

At Minimum, Check These Four Things Before Sending Any Payment

The first three are from the opening of this article. Add one more about documentation, and the checklist looks like this:

Get a contract or quote with the scope of work written down. Even if it's someone you've known for years, an email or chat that summarizes the agreed scope is still better than a purely verbal agreement.
Tie payments to verifiable progress in each milestone. Pay in proportion to how much work you can actually see has been completed.
Get a clear answer on domain and source code. Who holds them while the project is in progress, and what do you receive when the agreed milestones are reached?
Keep all evidence somewhere outside the other party's channels. Emails, chats, transfer slips — keep copies somewhere only you can access, not dependent on their app or account.

During the Project: Signs That Things Are Still on Track

What you should see at each milestone is something tangible that matches that phase. Early on, you should see a requirements summary or a rough outline of the system before a single line of code is written. Mid-project, you should be able to test actual features — even if not every section is complete — not just a progress report saying what percentage is done. If the point comes where you should be seeing something and all you receive is "almost ready," that's the moment to ask for specifics — don't wait until it's been a silent month, like in the threads above.

Closing Thoughts

I understand that starting with any new team requires a degree of trust — especially if you've experienced something like the threads described here, or even just heard these stories from others. What I'd like to leave you with is this: the three or four questions in this article can be asked of any vendor you're considering hiring, not just us. If they can answer clearly from the start, that's already a good sign.

Going back to the restaurant kitchen extension at the start: whether a contractor walks off the job or not, no one can know for certain in advance. But that restaurant owner was able to move forward, because what had been built was still there to work with. Every question in this article exists to put your web or system project in the same position — so that whatever happens, you still have a way to keep going.

If you have a project in mind, whether a website or a back-office system, feel free to reach out and tell us where your business is currently stuck. We'll answer these questions clearly from the very first conversation, before you have to commit a single baht.