PRODUCTS & SYSTEMS · 2026 · PUBLIC ACTOR · MARKET NOT VALIDATED
A notification that a tender has changed does not say enough. I wanted a record of what changed, where the source evidence sat and what a reviewer still needed to do. I first tested that idea as a revision-control service called BidDelta, then released KONEPS Live Tender Matcher, an Actor that normalizes notices from the official Korean procurement API.
The public products and the first buyer contacts are real. Purchases and verified revenue were zero in the ledger checked on 3 September. The next day, Apify displayed one total user and zero monthly active users. The page does not establish that the one user was an external customer.
BidDelta
before/after changes and open items
KONEPS Actor
public tool using an official API
Outbound test
contact forms and email
Purchases and revenue: 0
market not validated
The first product began with revisions that fell through the cracks
BidDelta initially targeted UK mechanical and electrical estimating teams. Drawings, specifications and addenda often change near a submission deadline. Even when a team notices a revision, it still has to establish whether the change was priced, qualified or queried, and which page supports that decision.
I defined the product as a page-linked change register and a handover of unresolved items rather than a generic change alert. Automated comparisons remained subject to human review. I built a sales page, scope and pricing documents, a case report based on real revisions, an operating procedure, a CRM and test material.
An external product listing preserves the public launch on 17 August 2026. I also made initial approaches through contact forms and email. Because records from several campaigns later became mixed, I do not publish an exact outreach count here. No positive response or purchase was verified.
Rate limits changed the operating design
Bulk requests ran into rate limits. Instead of adding more concurrent calls, I slowed the collection process and introduced retries. Before sending anything externally, I also rechecked a flawed target ranking and broken evidence links. Finding a difference mattered less than proving that the difference belonged to the right source document.
Comparisons against official procurement records reproduced the main change signals in several cases. That was technical validation. It did not show that a buyer would use the report repeatedly or pay for it.
I rebuilt the question around KONEPS public data
KONEPS Live Tender Matcher queries the Public Procurement Service’s official Bid Public Notice Open API. It filters service, goods, construction, foreign-procurement and other notices by date, keyword and region, then returns flat records for the notice number, agencies, budget, deadline, change status and authoritative source link. Official notice number and order fields drive deduplication; absent values remain null rather than being guessed.
Each user supplies a data.go.kr service key, which is treated as a secret input and excluded from the output. Results can be exported as JSON, CSV or Excel. The Actor discovers and organizes public notices. It does not decide eligibility, prepare a bid, sign declarations or submit anything to KONEPS.
BidDelta and the KONEPS Actor have different implementations and buyers. I keep them in one project lineage because the product question persisted: how can a procurement change reach a person together with evidence they can inspect? One answer was a document-comparison service; the other was a public Actor over an official API.
The public numbers do not yet describe a market
On 4 September 2026, the Apify product page displayed zero bookmarks, one total user and zero monthly active users. The display cannot tell me whether that user was an external person or one of my own tests, or whether a useful notice was retrieved. A public price also does not prove revenue.
The verified result is one public Actor, a surviving public launch record for BidDelta and actual outbound attempts. Purchases, recurring use, customer contracts and verified revenue remained at zero. The technical work could find a change and return to its source. It did not establish why somebody would pay for that difference instead of relying on free official alerts.
The system could find a change and link it to evidence. The sales test did not turn that difference into a reason to buy.
The next test
The next step is not another notice category. I would begin with one recent revision that a working bid team almost missed and test whether the current process recovers it. Time spent returning to the source, false changes, missed changes and the resulting action all need to be recorded. Repeated use in that small test would be a better reason to expand than another internal feature checklist.
Project record
Period: 2026
Role: product scoping, public-record normalization, change comparison, evidence linking, rate-limit and retry design, QA, release and initial outbound work
Internal artifacts: case report, CRM, operating procedure, unit tests and backtests
Externally observed: BidDelta launch trace, public Apify Actor and initial contact-form/email approaches
Not established: an external-customer attribution for the public user count, repeat use, purchases, contracts, revenue or bid outcomes
Apify status checked: 4 September 2026