Many of the clients reading this have worked with us for years. Some of you since the very first system we built, through every change we made along the way, and through the stretches when a deadline meant phone calls late at night.
So what we want to write about here is not an announcement that we have gained something. It is an account of what worries us, and what we decided to do about that worry.
What worries us, and what nobody talks about
We currently run several development projects at once: enterprise resource planning systems, systems that connect equipment on the factory floor, and web applications built to one organisation's particular requirements.
We are proud of our team. But we also know one plain fact: the quality of the work you receive still depends on the individual looking after your project more than it should.
That means if your project gets someone unusually thorough, the work comes out unusually thorough. And if that person moves to another project, or leaves, everything they were holding in their head leaves with them.
That is not fair to you. You did not buy one employee's ability. You hired a company.
So we chose the standard that answers exactly that
ISO/IEC 29110 is an international standard for software development processes, published by the International Organization for Standardization, and written specifically for small software organisations.
What made us choose it was not that it is international. It was one of its principles, which happens to match our worry precisely.
The standard does not measure the ability of individuals. It measures the ability of the organisation's processes.
พูดให้ตรงกว่านั้น การที่พนักงานคนใดคนหนึ่งของเราเก่ง ไม่ได้ทำให้เราผ่านการตรวจประเมิน และการที่คนคนนั้นลาออก ก็ไม่ควรทำให้งานของคุณสะดุด นั่นคือสิ่งที่เรากำลังสร้างให้เกิดขึ้น
The questions you may never have asked us directly
We know that when you decide to commission a system, there are questions in your mind that usually go unasked, because asking them can look like distrust.
Allow us to ask them on your behalf, and to answer plainly how this standard lets us respond.
First, will the work actually finish when you said it would? The standard requires a project plan, and progress records that compare the plan against actual results at the agreed intervals, rather than a report that says a great deal has been done with nothing to measure it against. You can ask to see those records every cycle, and we ought to be able to show you immediately without assembling anything new.
Second, what happens if the person looking after our system changes? The standard requires a project repository with backup copies, maintenance documentation, and traceability records linking your requirements to the design and on to the testing. The result is that your work lives in a system, not in someone's memory.
Third, will there be documentation for your team to read two years from now? The standard makes three documents non-negotiable deliverables: the user manual, the operations manual for system administrators, and the maintenance documentation. These are not extras, and you should write them into every contract, whether you hire us or someone else.
Fourth, will everything asked for at the start be there at handover? The document that answers this is the traceability record, which shows that every one of your requirements has a design that covers it and a test that exercised it. It can be checked quickly, and it tells you more than an hour-long project review meeting.
Fifth, and this is the one that affects your budget most. The standard requires every change of scope to have a written change request, and a correction register that tracks each one through to closure.
Let us be direct about this. Changes along the way are nobody's fault, and they happen on every project we run. What causes trouble is not the change itself, but the two sides remembering differently what was agreed and when. Keeping a record protects you as much as it protects us. It is not an extra procedure.
Something we think you should know, and may not have been told
There is one point here that concerns your money directly.
In Thailand, an ISO/IEC 29110 certificate is one of the documents required to list a product on the Digital Service Catalog, the state-verified register of digital goods and services. When you procure a product on that register, additional benefits apply to you.
| Benefit | What it is | Does it apply to you |
|---|---|---|
| Double tax deduction | Spending on digital goods and services listed on the Digital Service Catalog can be deducted at 200 percent, capped at 300,000 baht, effective from 24 June 2025 to 31 December 2027 | Every private-sector buyer |
| Counted as investment in full | Under investment promotion criteria, listed software counts in full as investment, while unlisted software counts as half | Factories and businesses holding investment promotion |
| Procurement by specific method | Under Ministry of Finance regulation No. 4 B.E. 2566, listed goods are treated as digital promotion supplies | Government agencies and state enterprises |
We want to be clear about two limits, so that nothing here is read as more than it is.
**First**, these benefits attach to the product being listed on the Digital Service Catalog, not to the developer holding a certificate on its own. Before you rely on them, check whether the product you intend to buy is already on the catalog, whether you are buying it from us or from another provider.
**Second**, tax measures and investment promotion criteria have expiry dates and conditions that change. Please verify them with your own tax adviser before using them in a decision. We should not be the ones advising you on tax.
What this standard cannot do
If we wrote only about the benefits, this article would be no different from a sales document, which is not what we want to put in front of you.
There are three things this standard does not guarantee.
**It does not guarantee software without defects.** The standard certifies that a testing process exists and that test results are recorded. It does not certify that every result passed.
**It does not guarantee the system will suit your business.** Whether the requirements are right still depends on your team working with ours. The standard makes what was agreed recorded and auditable, but it does not judge whether what was agreed was correct. That part still needs your time alongside ours.
**It does not guarantee price or schedule.** What it does is make changes in either one explainable.
Closing
We are telling you this because we think anyone paying for a system to be built deserves to know what their developer is trying to fix, not only to hear from them when something has succeeded.
If you would like to discuss how any of this applies to the work we are already doing together, or if there is anything you think we still do not do well enough, please tell us plainly. That is worth more to us than praise.
Thank you for the trust you have given us all along. We chose to take this on because that trust deserves evidence behind it, not only good feeling between us. You can read more about our development work on our contact page