From idea to venture record to application: the evidence chain

An idea is not yet an application. A useful application connects three different objects: the problem you want to address, the record of work that exists today, and the exact notice that asks for an application.

K-Startup's official portal lists startup-support announcements and organises support information into separate lines. The portal itself is the place to locate a current notice, but each notice remains the controlling document for its own applicants, dates, documents and evaluation process.

The idea is a question, not a qualification

Write the idea as a question that can be tested. Who has the problem? What do they do now? What change would make the idea useful? A founder who cannot answer those questions has a concept, not yet a venture record.

Keep the first note small. Name the customer group, the setting, the repeated task and the proposed test. Do not add a market size, revenue forecast or government-support claim unless you have a source for that claim.

The purpose of this stage is not to satisfy a programme. It is to decide what evidence would change your mind. A conversation may show that the problem is real. A prototype test may show that the proposed change is understandable. A paid transaction may show a different kind of evidence.

Do not call an idea validated because one person liked it. Record what the person did, what they declined to do, and what remains unknown. That discipline gives the later application a clean boundary.

The venture record is a dated trail

A venture record is the set of documents that shows what happened after the idea note. It can include customer interview notes, a prototype version, a test log, a signed letter, an invoice, a company-registration record or a prior programme result when those documents genuinely exist.

The record is not a claim that every test succeeded. A failed test can explain why the model changed. A cancelled pilot can show a risk. A rejected application can reveal an eligibility mismatch. Label each item as an observation, a document or an inference.

K-Startup's portal also exposes a founder to different support lines. That makes the record useful only when its entries are tied to the line being considered. A facilities notice may ask about occupancy or location. A commercialisation notice may ask about the item and execution plan. A mentoring notice may focus on the support need. The same founder can have all three records, but they are not interchangeable.

For a foreign founder, keep the original-language document and an English working note together. Translate the meaning you need for the application, but preserve the Korean title, issuing body and document date. If the current notice requires a particular certificate, find that requirement in the notice rather than assuming an English summary is accepted.

Match the record to one current notice

K-Startup's recruitment page distinguishes notices that are ongoing from notices that have closed. Start the application from the current notice page, not from a saved copy or a search result. Check the opening and closing dates, the named administering body, the support line, the applicant category and every required attachment.

Read the notice in this order:

1. Identify who may apply and how the notice defines the applicant.
2. Identify the business age, location, sector or other boundary fields.
3. Identify the required form and supporting documents.
4. Identify the submission channel and deadline shown in that notice.
5. Map each statement in your draft to a record item or to the notice itself.

The portal's categories are a discovery aid. They are not a universal eligibility rule. A notice can be posted under a broad line while adding its own applicant conditions. If a field is absent from the fetched notice, write “confirm against the current 공고” rather than borrowing a requirement from another programme.

The application should therefore contain fewer claims than the founder's complete story. Keep unrelated achievements in the ledger. Include only the evidence that answers the notice's questions and supports the proposed work.

Build the application from the chain

The strongest draft usually follows the same order as the evidence chain. First, state the customer and problem. Second, describe the work completed and the evidence it produced. Third, explain the proposed next step. Fourth, connect that next step to the support line and the notice's requested output.

Avoid a future-tense pile-up. “We will acquire users, enter markets and create jobs” is a plan, not evidence. Say what has happened, what the next funded or supported activity would test, and how you will record the result.

Use the notice's own vocabulary where it is clear. If the notice uses a Korean programme name, preserve it in the working record. Do not translate a term into a stronger promise. “Participation,” “selection,” “support” and “investment” are different events.

The final review is a traceability pass. A reviewer should be able to move from a sentence to its source document, then from that document to the applicant or activity it describes. If a sentence has no such path, remove it or mark it as a proposal.

When the record is ready, use the idea validation workspace to organise the evidence, then return to the current K-Startup notice before submitting. The portal is a route to an application, not a substitute for reading the notice.