The Competition Is Not the Competition
The thing people picture when they hear TEKNOFEST is the on-site stage: the track, the pool, the flight line, the judges. That part is real, and it is the shortest part of the process by a wide margin.
Most of a TEKNOFEST season happens in documents. Every category publishes a specification at the start of the cycle, and progress through the cycle is gated by written submissions delivered on fixed dates. Teams are filtered on paper long before anything is switched on. If you think of the competition as the event, you will spend the year building and lose in the spring for reasons that have nothing to do with your build.
What follows is what I would tell a team starting their first cycle. It is deliberately general — the specifics change per category and per year, and the published specification is always the authority.
Reports Are the Gate
Written reports decide who reaches the final. That is the single structural fact that reorganises everything else.
A design report is not documentation of work already done. It is an argument that your approach will work, addressed to reviewers who have never met you and will not ask follow-up questions. They read what is on the page. If a design decision is sound but unexplained, it does not exist. If a calculation is correct but the assumptions behind it are missing, it cannot be checked, and an unverifiable claim scores as a weak one.
This means the report has to be written from the reader’s side. State the requirement, state the option you chose, state the alternatives you rejected and why, then show the analysis that supports the choice. Include the numbers. Include the failure cases you considered. Reviewers are looking for evidence of engineering judgement, not enthusiasm, and judgement is only visible in the reasoning you show.
The practical consequence: reports cannot be written the week they are due, because writing them honestly requires having done the analysis. Teams that treat the report as a deliverable separate from the design end up documenting decisions they never actually made. It shows immediately.
The Calendar Does Not Negotiate
Deadlines in a competition are unlike deadlines anywhere else in student work. They do not move, they are not extended, and missing one ends the season. There is no partial credit for a report submitted late.
So the schedule has to be planned backwards from the fixed dates, with the uncomfortable parts placed first. Long-lead items — anything that must be ordered, manufactured externally, or approved — should be identified in the first weeks, because they set the earliest possible date at which a complete system can exist. Everything else fills in around them.
The other habit worth building early is scheduling for the version of the team that exists, not the ideal one. Members have exams. Suppliers are late. Parts arrive wrong. A plan with no slack is not an ambitious plan; it is a plan that will be wrong the first time reality touches it. Slack put in deliberately at the start is cheaper than slack taken by force in the final month.
Integration Is Where Teams Lose
If there is one prediction I would make about any first-year team, it is this: the subsystems will work and the system will not.
Individual parts get finished, tested in isolation and declared done. Then they are connected, and everything that was implicit becomes a problem — power draw under real load, mounting that fouls another component, timing between modules, a data format each side assumed differently, mass and balance that were fine per part and wrong in sum. None of these appear in subsystem testing, because they are not properties of subsystems. They are properties of the seams.
Integration also lands at the worst possible moment. It is last in the dependency order, so it inherits every delay upstream, and it is the phase most likely to reveal a problem that requires redesigning something already considered finished.
The counter-measure is to integrate early and badly. Connect incomplete subsystems as soon as they can exchange anything at all, even if half of them are placeholders. An ugly end-to-end system that barely functions tells you more about the real risks than three polished subsystems on separate benches. Freeze interfaces early, in writing, and treat any change to an interface as a change that affects every team, because it does.
What Actually Transfers
The value of the cycle is not the placement. It is that a competition imposes constraints that ordinary projects never do: an external specification you did not write, a deadline you cannot move, and a review by people with no reason to be generous.
That combination teaches scoping, written argument and honest scheduling faster than anything else I have done. Those skills outlast any single season.
Note: this entry is a structural placeholder. The competition record is accurate; the technical write-up still needs the owner’s own detail.