For most of my career, I have worked on complex technical systems. You may refer to my bio for more details. But recently I have been thinking about a different kind of system: how technical companies respond to RFPs, tenders and complex proposals.
I have been involved in enough proposals myself to know how quickly they become messy.
- Receive internal long-term roadmap from upper management.
- Analyze exact resources given previous successful proposals and projects.
- Plan potential tasks for future proposals.
- A new tender arrives.
- Understand it.
- Decide whether it is worth pursuing.
- Requirements to be extracted.
- Previous material needs to be found.
- Technical experts team need to contribute.
- Missing information generates more questions.
- Commercial, technical and management teams need to align.
- Compliance to be checked.
- Everything to come together before a tight deadline.
And somewhere in that process, a surprising amount of expensive human time disappears. My question is simple:
Where exactly does that time go—and which parts can realistically be removed without reducing proposal quality?
I don't yet know the answer. That is precisely why I am starting this research.
1. Start With Why
As an engineer, my natural reaction to inefficiency is dangerous: See problem → imagine system → build system.
To me, it feels productive, feels natural. But it is also a very effective way to spend next six months building something nobody cares about. I (just like most of the tech industry) have also been guilty of wasting several years building technologies and capabilities that nobody wants. Hence this time, as Simon Sinek puts it, I must start with why.
The RFP technology market already contains sophisticated products. Loopio says its platform is used by more than 1,700 organizations and has handled over 500,000 projects. Its product already combines reusable content, AI-assisted responses, SME collaboration and workflow management. (Loopio)
Responsive goes even further. It combines requirements analysis, centralized organizational knowledge, AI-generated responses, project management, governance and integrations with existing tools. More than 2,000 companies use its platform. (Responsive)
Newer companies are pushing further still. GovDash has expanded from proposal generation into opportunity discovery, capture, pricing and contract management for US government contractors. In January 2026, it announced a $30 million Series B after reporting 16× revenue growth. (GovDash)
So clearly the answer is not:
“Companies need an AI that writes RFP answers.”
That product already exists. The more interesting question is:
If these tools already exist, why are proposal teams still struggling?
That is what I want to understand.
2. The Problem May Not Be Writing At All
My current hypothesis is that proposal writing is only one visible part of a much larger operational problem.
Consider a technically complex bid. The useful knowledge may exist across:
- previous proposals;
- SharePoint folders;
- technical reports;
- emails;
- product documentation;
- spreadsheets;
- project records;
- individual engineers' experience;
- legal or compliance documents;
- conversations that were never documented properly.
The problem is therefore not necessarily:
“Can AI write this paragraph?”
But rather, it may be:
“Can the organization reliably find the correct information, determine whether it applies, identify what is missing, get the right human involved and produce a defensible answer before the deadline?”
Those are very different problems. This distinction matters because modern RFP platforms are already moving in exactly this direction.
Responsive, for example, connects organizational knowledge with workflow and governance rather than treating an RFP as an isolated document. Its platform can connect with tools such as SharePoint, Google Drive, Teams, Salesforce and other enterprise systems. (Responsive)
Arphie similarly connects repositories such as Google Drive, SharePoint and Confluence, then uses those sources to generate cited responses and support collaboration. One published customer case study reports reducing RFP work from approximately 20 hours to two hours. (Arphie)
Those are impressive results. But they also make me more interested in talking to actual proposal teams. Because software capabilities do not automatically tell us what happens inside a real organization.
3. Singapore Makes This Particularly Interesting
Singapore is aggressively pushing businesses toward deeper AI adoption. Yet adoption and meaningful integration are very different things.
In April 2026, Singapore's Ministry of Manpower reported that 71.5% of firms had not yet adopted AI. Among firms using AI, 70.7% reported productivity improvements. But companies also reported significant barriers: implementation cost, lack of internal expertise, integration complexity and data-security concerns. (Ministry of Manpower Singapore)
For larger organizations, integration with existing systems was reported as a challenge by 56.1% of firms, while 55.4% cited data privacy or security concerns. Meanwhile, Singapore's National AI Impact Programme aims to help 10,000 enterprises deepen their use of AI over three years. (Singapore Labour Market Statistics, Digital Development Ministry)
That suggests something important. The opportunity may not be creating another AI model. It may be the much less glamorous work of figuring out:
How do we make AI useful inside an existing business process without destroying trust, introducing errors or forcing everyone to completely change how they work?
That is much closer to a systems-engineering problem. And that is the problem I am interested in.
4. Where I Expect This Idea To Fail
I am deliberately trying to identify the reasons this research could prove me wrong.
4.1. Failure 1: The Pain Is Not Economically Important
Proposal teams may dislike parts of their workflow without those problems costing enough money to justify fixing them. Saving someone 20 minutes once a month is not a valuable impact. Saving several senior engineers dozens of hours every week might be. I therefore need to understand not simply what is irritating, but:
frequency × people involved × time consumed × value of those people's time × business consequence.
4.2. Failure 2: Existing Software Already Solves The Important Problems
This is entirely possible. If a company's real problem can be solved by correctly configuring Loopio, Responsive, Arphie, Microsoft Copilot or another existing system, I should not work on solving the same problem. Perhaps the valuable service is implementation, integration, or process redesign. Perhaps it's nothing. The research needs to determine that.
4.3. Failure 3: Every Company's Workflow Is Different
If I interview ten companies and discover ten completely unrelated problems, there may be nothing repeatable enough to build. A scalable solution requires some common structure. My current objective is therefore not to collect interesting complaints. I also eagerly am looking for recurring bottlenecks across multiple organizations.
4.4. Failure 4: Confidentiality Makes Useful Automation Impractical
Proposal systems touch sensitive information.
Pricing. Capabilities. Customer information. Technical designs. Commercial strategy. Previous bids.
Security cannot be treated as an afterthought. The fact that leading vendors prominently emphasize governance, access controls, source traceability and enterprise security tells me that this is likely to be one of the central adoption barriers, not merely an IT checkbox. (Responsive)
4.5. Failure 5: AI Produces Answers, But Humans Still Have To Verify Everything
If AI saves ten minutes drafting but creates twenty minutes of checking, nothing has been automated. For a high-stakes technical proposal, a confident but incorrect answer can be worse than no answer. The system therefore has to preserve something I care deeply about:
traceability.
Some key questions that I could examine:
- Where did this claim come from?
- Is the source still valid?
- Does it actually answer the requirement?
- What requires human judgment?
- What should never be automated?
4.6. Failure 6: I Build Too Early
This is probably the failure mode I am personally most vulnerable to. I enjoy building systems. That means my competitor may not need to defeat me. I can defeat myself by spending months engineering an elegant platform before understanding what anyone wants. So I am imposing a rule on this project:
Research first. Solution later.
5. What I Am Actually Trying To Learn
Over the next stage of this research, I intend to speak with people who are directly involved in complex technical bids in Singapore. Subject-matter experts who repeatedly get dragged into proposal responses such as following.
- Business development managers.
- Proposal and bid managers.
- Commercial leaders.
- Technical directors.
- Sales leaders.
I am particularly interested in technical B2B companies—engineering, systems integration, cybersecurity, industrial technology and other businesses where proposals require genuine technical judgment. This also aligns deeply with my engineering, science and deep tech research skillset.
Singapore's GeBIZ portal makes this an especially interesting market to study because public-sector quotations and tenders are centrally published, and awarded results can reveal which companies are actively participating in government procurement. (GeBIZ)
But I am not looking for confidential proposals. I don't need pricing, customer secrets or proprietary technical information. I want to understand the process. For example:
Walk me through the last complex tender your team responded to.
- Who first saw it?
- How did you decide whether to bid?
- Who interpreted the requirements?
- How many people became involved?
- Where did you search for previous answers?
- Which questions required SMEs?
- What generated the most back-and-forth?
- What had to be checked manually?
- What nearly went wrong?
- What did your most senior people spend time doing that they probably should not have been doing?
And, perhaps most importantly:
If you could permanently remove one part of that process tomorrow, what would you remove?
Ten conversations like this would teach me more than months of speculative software development.
6. What Success Would Look Like
I am not trying to prove that AI belongs in every proposal workflow. Quite the opposite. A successful outcome from this research might be discovering that most of the process should remain human.
Perhaps only requirements extraction should be automated. Perhaps retrieval of previous approved material is the real bottleneck. Perhaps SME coordination matters more than drafting. Perhaps compliance QA is the expensive problem. Perhaps bid/no-bid decisions consume enormous amounts of senior-management attention. Or perhaps I discover that the existing software is already good enough and there is no meaningful problem left for me to solve.
That would also be a useful result. Because my objective is not to justify building a product. My objective is to find the truth.
7. If A Useful Opportunity Does Exist
Only after seeing the same problem repeatedly would I start experimenting with solutions. And even then, I would begin manually. The first version might be nothing more sophisticated than a combination of:
RFP → structured requirements → previous knowledge retrieval → missing-information questions → SME inputs → sourced draft → compliance review → human approval.
Some parts might use AI. Some might use existing RFP software. Some might require Python or custom integrations. Some should probably remain entirely human.
I do not care which technology wins. I care whether the process becomes meaningfully:
faster, easier, safer or more reliable.
Eventually, if the same workflow appears repeatedly across multiple companies, then perhaps there is something worth turning into software.
But that is a future decision. For now, I am trying to earn the right to build it.
8. I Would Like To Learn From People Doing This Work
If you lead business development, bids or proposals for a technical company in Singapore, I would genuinely value your perspective. I am looking for a small number of people willing to spend around 20–30 minutes walking me through how their team handles complex tenders.
No confidential documents or commercially sensitive information are required.
I am not trying to sell anything. I am just trying to understand where the real bottlenecks are before deciding whether anything should be built at all.
Once I have enough conversations, I also intend to share the aggregated patterns I find—what repeatedly consumes time, what teams already automate successfully, what still requires human judgment, and where AI appears genuinely useful versus merely fashionable.
If this research eventually produces a useful system, excellent. If it proves that my assumptions were wrong, that is also progress. If you think you can contribute to this work and rest of the community, please feel free to reach out to me.