A tender revision notice still leaves work for an estimator: locate the changed page, decide whether to alter the price, and keep track of unanswered questions. I wanted to connect those decisions to the documents behind them. I first scoped BidDelta for UK mechanical and electrical estimating teams, then released KONEPS Live Tender Matcher to retrieve and organize official Korean procurement notices.
The tools operate on different material. BidDelta concerns changes in drawings, specifications and addenda. The KONEPS Actor organizes notices and change indicators supplied by an official API. It does not compare two documents to calculate their differences or submit a bid.
Keeping a source page beside a change
For BidDelta, I defined a page-linked change register and a handover of unresolved items. The record needed to help a person decide what to price or query, with automated comparisons subject to human review.
I prepared the sales page, scope and pricing documents, a report based on real revisions, operating procedures and a prospect-management sheet, alongside unit tests and comparisons with earlier cases. Bulk requests hit rate limits, so I changed the collection approach to slower requests and retries. Before outreach, I also rechecked errors in the prospect ranking and broken evidence links.
The contemporary record describes checks of key change signals against several official procurement records and initial approaches through contact forms and email. A KBlip product entry dated 17 August 2026 preserves the UK estimating-team scope. It is a trace of the launch description, not evidence of a customer contract.
Turning KONEPS notices into rows
KONEPS is Korea's public procurement system. I used the Public Procurement Service's Open API—the interface through which a program requests data—rather than reading the website visually. The implementation selects the appropriate operation for services, goods, construction, foreign procurement or other notices, and queries a range of registration or change dates. I released it as an Actor, an executable program on Apify. Public Actor · Official API source
After keyword and region filtering, each notice becomes one row containing its number, title, agencies, budget, deadline, change status and source link. This normalization puts nested source data into consistent columns that can be exported as JSON, CSV or Excel. Region filtering matches text in the available region and agency fields; it is not an eligibility decision.
For duplicates, I used the official notice number and order together: bidNtceNo + bidNtceOrd. Within that combination, a record with a later change timestamp takes precedence, while non-empty values from the other record can fill gaps. Only when the official number is absent does the implementation derive an internal identifier from the business type, title, agency and deadline. That fallback helps deduplicate the output; it is not a new official notice number.
Budget normalization also keeps its source visible. The code chooses the first available value from allocated budget, notice budget and estimated price, then retains both the selected field name and the three original amounts. An absent amount remains null, meaning no value was supplied, rather than becoming zero. Keeping those fields allows a reader to see when apparently comparable amounts came from different kinds of source figure.
What the change flag means
The Actor marks a notice as changed when it was retrieved by change date, or when the official response supplies a change time, reason or changed-notice label. That flag does not come from a before-and-after document comparison. I kept the source link and change reason so the output could lead a person back to the notice. The tool is unofficial and unaffiliated with PPS or KONEPS; the original notice remains authoritative.
I limited an inclusive query range to 31 days and added page and result caps. Temporary server failures and per-second rate limits receive up to three attempts by default, waiting 250ms and then 500ms before retries. Approval or input errors are not retried indiscriminately. With onlyOpen enabled, a notice without a deadline is excluded too: a missing date does not establish that bidding is still open.
Users supply their own data.go.kr service key. It is configured as a secret input, excluded from results and redacted from error messages in both its raw and URL-encoded forms. On 7 September 2026, code review and ten passing offline tests covered date handling, response shapes, deduplication, spending limits and key redaction. These tests did not exercise a live PPS query and payment with a real key.
Bounding a run before it produces results
For paid runs, I connected each returned notice to one result event. If the default dataset-storage charge is configured alongside the result charge, the program stops before collection to avoid that double-charge configuration. When both an input spending cap and a platform run cap are present, the lower value applies; output also stops when the platform reports that its event limit has been reached.
The public AI and automation service-tender example is configured for at most ten results and a USD 0.01 event-spend cap. Its saved dates are 30–31 August 2026, so a new search needs an appropriate date range and the user's own service key. A configured example is not itself a completed query result.
The public state after release
On 7 September 2026, the public page and official public API still showed the Actor as public, with latest build 0.1.6. The page displayed one total user, zero monthly active users and zero bookmarks; the API reported zero total runs. The user counter alone does not establish an external customer.
BidDelta reached initial outreach, but the record checked on 3 September showed no purchases or revenue. I did not establish any subsequent contract or cleared payment in this review. The two implementations leave different kinds of records: one connects a document revision to its source page and outstanding decisions; the other puts official notices into consistent columns for further checking. Whether customers use either record repeatedly in their work remains a separate question.