Most IT projects don't fail in the code. They fail in the scope.
Between a TOR written broadly and a system nobody ends up using, there is a stretch that no one owns outright — internal IT has fewer people than projects, the contractor answers only for what is in the contract, and the executive sees a status report. We close that gap as a technical advisor working through your own IT function.
Our executives bring vision and experience from international companies and work to international standards and culture. They have built and worked alongside engineers of many nationalities, and they understand how Thai people work, how to approach them and how to show respect. That doesn't give Gomusoft a certificate. It does mean we're familiar with the questions a board, an auditor and a foreign parent company will ask — and with the difference between an answer that survives them and one that doesn't.
And most of our engagements start with a single project, not an organisation-wide transformation.
No bid on work we advise on
If we help draft the TOR or advise on contractor selection for a project, Gomusoft will not bid to build that project. We will put that in the contract.
When organisations call us
Five situations that keep recurring
None of these is any single contractor's fault. Most of them are what happens when the business need and the technical specification are written at different times by different people.
Scope moves after signature
The TOR was written broadly enough that every party read it differently. Once delivery starts, the differences become change requests that nobody is empowered to settle quickly, and the budget and the date move with them.
Technical proposals that can't be compared
Each bidder proposes a different architecture, in different vocabulary, priced on a different basis. When the technical comparison can't be made, the decision defaults to price.
Security and personal-data questions you can't answer
The board, internal audit or the parent company asks where the data sits, who can reach it and how PDPA is satisfied. The only people who can answer are on the contractor's side, and the answer arrives as marketing material rather than a data-flow diagram.
Delivered, but the front line doesn't use it
The system passed acceptance, and the staff went back to spreadsheets and email attachments — because acceptance measured features, not whether the actual work now runs through the system.
Requirements that distort in translation
When the development team or the parent company sits abroad, the business need passes through several translations. What comes back matches the document and misses the work.
All five share one underlying condition: nobody on your side reads both the contract and the code.
What the role covers
A technical advisor working through your IT function
- Reviewing the TOR and technical specification before it goes out — finding the clauses open to several readings, the acceptance criteria that can't be measured, and the things left unwritten that become costs later.
- Interrogating technical proposals — we provide the questions and the checks that let your own people compare bids. We do not rank named contractors.
- Holding scope and change during delivery — writing acceptance criteria that can actually be measured, reviewing each milestone properly, and separating a genuine change request from something already in scope.
- Reviewing architecture and data flows with your IT team — as a review that produces an opinion. Approval stays with IT and the budget owner, always.
- Working with the people who must use the system, so that acceptance measures whether the work now runs through it — and so that user transition sits in the project plan from the start rather than being appended at handover.
- Translating between the business and the engineers, including engineers abroad — writing requirements in a form a developer can act on without guessing.
- Continuous development in a product-owner role — when the organisation needs one person holding the continuity of one system across the year.
Reporting line and independence
We are not here to replace your IT function, or to go around it
Your internal IT team knows the legacy systems, the constraints and the internal politics better than any advisor learns in three months. Our job is to add capacity to that team when there are more projects than people — not to mark their homework.
- We report through IT, or through the executive IT reports to, as the organisation decides — never over IT's head.
- Technical approval and budget decisions remain entirely the organisation's. We give a written opinion and stand behind it.
- If we help draft the TOR or advise on contractor selection for a project, Gomusoft will not bid to build that project. We will put that in the contract.
- We take no fee, referral payment or commission from any contractor, software vendor or cloud provider, and we will disclose any pre-existing relationship in full.
- We don't comment publicly on any contractor by name. What we hand over is the set of questions to ask and the evidence to ask for.
Stated plainly
What exists today, what can be arranged, and what does not exist
Most procurement checklists have boxes Gomusoft cannot tick. They are listed here so you don't have to discover them in the third meeting.
True today
- Our executives' direct experience of working inside international organisations that had to survive heavy scrutiny, and familiarity with the questions a board, an auditor and a parent company will ask.
- A written data and access practice you can inspect during the engagement.
- A documentation standard delivered every milestone: architecture, data flows, deployment procedure, a credential register with owners, and an open-items list.
- The organisation owns the source code, the data and every service account from day one — not at handover.
- NDA and personal-data processing agreement (DPA) signed on your organisation's own template.
- Working under your own security policy, and remediating findings from your security function's scans or reviews on an agreed severity schedule.
- We do the work. The person you brief is the person who decides and builds; nobody is swapped in after signature.
Can be arranged if written into the contract (with cost and lead time)
- A third-party penetration test — we arrange the engagement, open the system to the tester and remediate the findings. The tester's fee sits in the project budget.
- A source-code escrow agreement with an external agent, on agreed release conditions.
- A named backup engineer written into the contract, with access pre-arranged and a stated time to take over.
- A data-residency requirement — deployed on your own infrastructure, or pinned to a Thailand cloud region, as the organisation requires.
- A service-level agreement with an escalation path, within hours we can genuinely honour.
- A written architecture review with data-flow diagrams, the points at which data is encrypted, and a complete list of external processors.
Does not exist today
- Gomusoft holds no ISO/IEC 27001, SOC 2 or any other security certification, and is not currently in the process of obtaining one.
- There is no existing third-party penetration-test report to attach to a proposal.
- There is no 24/7 monitoring centre and no round-the-clock on-call rota.
- No escrow agreement is currently in force; one has to be set up per engagement.
- There is no large permanent staff. Gomusoft is not a company with a bench waiting to rotate in.
- There are no publishable outcome figures — adoption rates, return on investment from earlier work. We have no client-cleared numbers, so we quote none.
If anything in the third column is a mandatory procurement condition, we will say so in the first meeting — this isn't our project — and help you write the requirement so you can find someone who qualifies.
Structure and invoicing
Three levels of commitment, starting with the easiest to stop
Step 0 — a paid assessment
A fixed, short, self-contained scope delivered as a document: findings, risks in priority order, and a recommended next step. The document belongs to the organisation and can be used with any contractor. Nothing obliges you to continue with us.
We charge for this because free analysis tends to be worth what it costs, and because most of the budget has usually gone to the previous contractor. Paying once, in a small amount, to learn what should happen next is a better use of what's left.
Model 1 — technical advisor and TOR review
Engaged per deliverable, or monthly against an agreed number of working days. Every period produces documents and meeting records. It fits the run-up to procurement, bid evaluation, and acceptance.
Model 2 — continuous development in a product-owner role (the one that survives procurement best)
A quarterly or annual contract, invoiced monthly, with a plan and a goal for each cycle and a report at the end of it. The advantage for the organisation is that priorities can be reset each cycle inside the existing contract, without reopening procurement every time the business need changes — which is the main reason fixed-scope projects finish misaligned.
The total contracted scope is fixed; what flexes is the priority order inside it, not an uncapped addition of work.
Model 3 — partnership with shared upside
This generally does not fit bodies with procurement regulations and conflict-of-interest rules. It sits on a separate page so it never mixes with an organisational proposal.
Read the partnership page →All paperwork is issued by the legal entity, Gomusoft Co., Ltd., and supports vendor registration, withholding tax and your own billing cycle.
No prices are shown here. They depend on scope and duration, and we always quote in writing.
Continuity
The question you should ask us in the first meeting
We have a team we've chosen and coach continuously, but the person you brief is the person who decides, designs and does the core work; the team does the rest under our review. The person accountable is never substituted after signature. Key-person risk is still real and still has to be managed — but a team that already knows this system is the first layer of protection, not an outsider starting from zero. So here is the whole answer, rather than waiting for procurement to ask.
Documentation standard
Every milestone ships documentation alongside code: architecture, data flows, deploy and rollback procedures, a credential register with owners, the reasoning behind significant technical decisions, and the open-items list. The standard we hold it to is that an engineer of comparable ability can pick the work up from those documents.
You own everything from day one
The repository, cloud account, domains and third-party service accounts are in the organisation's name and paid for by the organisation from the start. We are a user granted access, and our access can be revoked immediately without affecting the system.
A handover clause in the contract
Stating notice periods on both sides, a transition window, the handover inventory, and our attendance at handover sessions with whoever takes over — regardless of which side ends the contract.
A named backup, and how extra capacity is sourced
If the organisation requires it, we name a backup engineer in the contract with access arranged in advance. Work beyond what we can do alone is done by a team we've chosen and coach continuously, under the same NDA with least-privilege access. If a period needs capacity beyond that team, we contract per project with engineers we have worked with directly and whose work we review ourselves. Accountability to the organisation remains ours alone. We don't quote headcount or names. We can tell you a team exists, and describe roles — not the number of people or who they are.
Source-code escrow
No escrow is in force today; it can be arranged with an external agent on release conditions you set, with cost and lead time in the project contract. Worth noting: once the repository lives in your account from day one, escrow adds less than is usually assumed. The real question is who takes the work over, not who can reach the code.
Service levels, and the limit we state up front
We commit in writing to response and start-of-remediation windows within business hours, with an escalation path that names a real person and a real channel. Outside office hours, someone can pick things up on a best-effort basis, but we don't promise a guaranteed response time or an SLA after hours. What we don't have is a 24/7 on-call rota. If your system needs round-the-clock monitoring and response, that belongs with a provider who runs an actual operations centre. We'll help you specify it and hold them to it — we won't pretend to be it.
Why we take on a limited number of engagements
Because we design, do the core work, and review everything ourselves before it reaches you, our own review capacity is the limit — not the size of the team. The number of engagements we can hold at once is naturally limited. That isn't a marketing policy; it's the fact our service levels have to be written from. If the window you need doesn't match what we can take, we'll say so at the start.
Data, access and PDPA
The full answer sits on its own page: where data lives, who can reach it, how credentials are handled, who owns the code and the data, what happens when an engagement ends, and how a security question gets answered mid-project. It also marks which items are a practice and which are certificates Gomusoft does not hold.
Security and data →What procurement and audit always ask
Is Gomusoft ISO/IEC 27001 or SOC 2 certified?
No, and it is not currently pursuing either. What we have is a written practice you can inspect during the engagement, and a willingness to work under your own security policy and audit process. If certification is a mandatory procurement condition, Gomusoft does not qualify — and we'll tell you at the outset.
Will you sign a DPA, and how is PDPA handled?
Yes, on your template. In most engagements your organisation is the data controller and we process on your instructions. Gomusoft has no counsel-reviewed DPA template of its own, so we use yours. The practice we hold to: real personal data does not leave your environment for development or testing, and your data is never used to train or tune any AI model. Draft
Do you have third-party penetration-test results?
There is no existing report to attach. What can be done is to write an external test into the project contract: we coordinate it, open the system to the tester and remediate on an agreed severity schedule. If you already have an internal security function or a testing contractor, we work with them directly.
Can we get an architecture review with data flows and encryption points?
Yes, and we treat it as a standard deliverable: a written review with data-flow diagrams, where data is encrypted in transit and at rest, a full list of external processors, and any point at which data leaves your boundary. Your IT and security functions sign it off — not us.
What are your SLA numbers and escalation path?
We commit in writing to response and start-of-remediation windows in business hours, with severity levels, a reporting channel and a named escalation contact if we don't respond. The figures are set together against the nature of the system; we don't publish numbers in marketing material. The limit to know in advance: we have no 24/7 on-call. If the system needs it, that belongs with a provider who runs an operations centre, and we can govern them on your behalf.
Where will the data reside?
Wherever the organisation specifies. The two usual options are your own infrastructure, or a cloud account in your name pinned to a Thailand region. For a short prototype it may sit temporarily in a Gomusoft environment — agreed and stated in advance, and with synthetic data only.
If we terminate, what do we take with us?
Everything, because everything is already in your name: the full source code with its history, the data in a standard, importable format, the architecture and deployment documentation, the credential register with owners, and the open-items list. We don't build architectures or data formats that oblige you to come back to us, and we're happy for that to be a contract clause.
If you're unavailable, who continues — and how many people is Gomusoft?
We have a team we've chosen and coach continuously, but we don't quote headcount or names — decide from the continuity answer below, not from a number. The continuity answer has five parts: a documentation standard that lets an engineer of comparable ability take over; your ownership of the code and every account from day one; a handover clause in the contract; a named backup engineer written in beforehand if you want one; and our own team, who already know this system — not outsiders starting from zero — with per-project capacity sourced from engineers we've worked with directly and whose work we review, if ever needed. If that risk still sits above your threshold, the honest conclusion is that you should choose a contractor with a larger standing team.
Can you do source-code escrow?
Yes, per project, with an external agent on release conditions you set. None is in force today. One useful observation: when the repository is in your account from day one, escrow adds less than expected. The real exposure is finding a successor, not reaching the code.
Are you here to replace our IT function?
No. We work through IT and report on whatever line the organisation sets; technical approval stays entirely with IT. In practice the person who gains most is an IT head with more projects than people, who gets someone able to read both the contract and the code on one project, without adding permanent headcount.
If you help draft the TOR, can Gomusoft then bid to build it?
No. If we help draft the TOR or advise on selection for a project, Gomusoft will not bid to build that project, and we'll put it in the contract. We also take no fee or commission from any contractor or vendor, and disclose any pre-existing relationship in full.
How do you handle vendor registration and procurement paperwork?
Everything is issued by Gomusoft Co., Ltd. and supports vendor registration, withholding tax and your billing cycle. If procurement has a supplier-assessment form or a security questionnaire, we complete it ourselves and answer truthfully — including the boxes where the answer is "We don't have this".
Start with one meeting, not a proposal
Tell us where the project stands — before procurement, mid-build, or delivered but unused. We'll tell you plainly where we can help, where we can't, and what belongs with a provider holding qualifications Gomusoft doesn't have. We reply directly.