AI4Elections Hackathon: How Nigerian Innovators Can Build a Strong Entry

The #AI4Elections Hackathon 2026–2027 invites Nigerian citizens aged 18 and above to develop practical, nonpartisan technology for electoral information, inclusion, cybersecurity, data analysis and citizen accountability. Individuals and teams of up to four can apply by 12 November 2026 at 11:59 p.m. WAT. Selected participants will develop and test their solutions during a programme culminating in a prototype submission deadline of 13 December. The announced cash prize pool is ₦10 million.

What applicants should understand before applying

Rise Networks is leading the hackathon in collaboration with INEC, Meta, Google, Microsoft and other partners. The programme aims to support practical technology addressing electoral challenges ahead of Nigeria’s 2027 general elections. The launch and partner details have also been reported by Premium Times.

The competition is not simply an invitation to propose an interesting use of artificial intelligence. Applicants are expected to develop a working solution or technically credible proof of concept. A presentation, wireframe or attractive interface cannot substitute for a functioning core feature.

That requirement should shape the project from the beginning. Rather than attempting to build an entire election platform, applicants are better served by defining one user problem, one useful output and a credible way to test whether the solution works.

Who is eligible, and what must applicants submit?

The competition is open to Nigerian citizens aged 18 and above, including students, recent graduates, researchers, developers, cybersecurity professionals, civil society practitioners, designers, linguists and other relevant specialists. Previous experience building AI systems is not mandatory for every track.

Applicants may enter individually or in teams of up to four members. Each team member must register individually and be identified as part of the same team before the deadline. An individual may participate in only one entry, and team membership cannot be changed after the hackathon begins. Applicants working alone may participate in structured team matching.

Applications must be submitted in English. Projects that have already received grants, awards or recognition in another competition are not eligible under the published call.

The initial application requires information about the applicant’s relevant skills or experience, preferred challenge area, project interests, team details where applicable, and a short explanation of the electoral problem they want to address.

A complete technical submission has broader requirements. Participants are expected to provide a clear problem statement, a working prototype or credible proof of concept, technical documentation, evidence of testing, an honest account of limitations, privacy and security considerations, a presentation explaining potential usefulness, and a two-minute video demonstrating the solution.

Applicants should use the official AI4Elections application portal to review the requirements and submit their details before the deadline.

Choosing a project that can be built and tested

The organisers have identified five main challenge areas. The practical task for an applicant is to turn one of them into a manageable development project.

These are illustrative project directions, not official selections or guaranteed winners. Climate resilience is an optional cross-cutting theme that may be incorporated into any of the five areas; it is not a separate track.

Before committing to an idea, applicants should apply five practical tests:

1. A defined user: Can the team identify who experiences the problem and what that person needs to do?
2. An appropriate data source: Can the project work with public, synthetic or expressly authorised data without requiring privileged electoral access?
3. A demonstrable core feature: Can the team show the central function working, even if the final product remains small?
4. A testable result: Can the team check the output against a known reference, repeat a procedure or document a meaningful limitation?
5. A responsible failure mode: What happens when the system is uncertain, receives misleading input or cannot verify a claim?

An idea that cannot satisfy these conditions may need a narrower scope before development begins.

A worked example: a voter-information assistant

Consider a hypothetical team building a small assistant that helps users find answers to selected electoral-information questions using approved public documents.

The first version would not attempt to answer every question about elections. It would cover a defined set of topics supported by the documents available to the team. Each factual answer would show its supporting source and, where relevant, the document date. If the evidence does not establish an answer, the assistant would say that it cannot verify the information instead of generating a plausible response, the design creates a practical prototype that can be tested without claiming to replace official electoral guidance.

The team could prepare a test set containing questions that are answerable from its source material, questions the documents do not address, ambiguous questions and differently worded versions of the same question. For each test, it would record whether the response is supported, whether the source is correctly identified and whether the system handles uncertainty appropriately. This is Tech View Africa’s suggested evaluation method, not a competition-mandated test set.

The resulting evidence would help answer three questions: Does the tool perform its intended task? Where does it fail? Can a reviewer understand and reproduce the team's evaluation?

The team should also avoid collecting unnecessary personal information, disclose the limits of its source material and maintain human oversight. The point is not to claim that the assistant can guarantee electoral accuracy, but to demonstrate a narrow function and provide evidence of how reliably it operates.

The same approach can be adapted to data analysis, observation reporting, accessibility or cybersecurity: define the task, demonstrate the core function, test it against known conditions and document the limits.

What the judging criteria mean for project design

The published judging framework assigns 25% to technical functionality and innovation, 20% to electoral relevance and practical usefulness, 20% to cybersecurity, privacy and responsible AI, 15% to inclusion and accessibility, 15% to scalability and feasibility, and 5% to demonstration and documentation.

The weights provide a useful way to prioritise development. Technical functionality and electoral usefulness together account for 45% of the score. Security, privacy, responsible AI, inclusion and accessibility account for another 35%. Scalability and feasibility carry 15%, while demonstration and documentation carry 5%.

This distribution supports a clear planning principle: teams should make the core solution work and show why it addresses the chosen problem before spending disproportionate time on presentation or unnecessary features. At the same time, safety and inclusion cannot be treated as optional extras because they are explicit judging criteria and programme requirements.

A practical readiness check is to ask whether another person can use the prototype, understand its intended purpose, see evidence that it was tested and identify what it cannot reliably do. If those questions remain unanswered, adding more features may not be the best use of development time.

The timeline: from application to prototype

The published programme schedule leaves a short period for implementation after problem validation and technical preparation.

The development sprint runs for 16 calendar days, from 28 November through 13 December. The preparation period before it is therefore important: applicants should already have a defined problem, a realistic idea of their technical approach and a team structure that suits the task.

A suggested 16-day plan is to establish the working prototype and data flow in the first three days, complete the core function over the next four, use the middle of the sprint for repeatable testing, then address failures and safeguards before freezing the submission. The final two days should be reserved for documentation, the demonstration video and submission checks not for starting an entirely new feature.

This is TVA’s recommended workflow, not an additional timetable imposed by the organisers. The official schedule and any later instructions should take precedence.

Prizes, support and the rules applicants should not overlook

The announced cash prize pool is ₦10 million. The overall winner is due to receive ₦4 million, the runner-up ₦2.5 million and third place ₦1.5 million. Four special awards of ₦500,000 each recognise research and policy innovation, electoral and civic inclusion, responsible AI and safety, and cybersecurity and resilience.

The programme also offers virtual technical bootcamps, mentoring and workshops. Microsoft Azure credits are subject to applicable terms and allocation limits, while laptops and other devices are included among the potential prizes. Promising projects may be considered for further development through the AI4Elections Development Hub. These benefits should not be read as guaranteed rewards for every applicant.

The nonpartisan rules are equally important. Participants must not develop partisan voter-persuasion tools, conduct political micro-targeting or attempt to manipulate electoral participation. They may use only synthetic, public or expressly authorised data. Testing live electoral systems or accessing confidential institutional information requires explicit written authorisation.

Winning the competition does not automatically approve a project for deployment by INEC or another institution. Any future operational use would require the relevant institutional, technical, legal and security approvals. Applicants should review the full competition terms, including intellectual-property, data-protection and prize conditions, when these are provided during the programme.

Before you apply

Use the remaining time to define a specific problem, select the most suitable challenge area and decide what working feature you could demonstrate. Check that your data source is authorised, that you can evaluate the result and that the proposed tool can fail safely. Team applicants should ensure every member completes individual registration and that the team is identified before the deadline.

Applications close on 12 November 2026 at 11:59 p.m. WAT. Questions about the application process can be directed to [comms@risenetworks.org](mailto:comms@risenetworks.org).

The strongest starting point is not the broadest idea or the most elaborate pitch. It is a clearly defined electoral problem, a working feature that addresses it and credible evidence showing what the solution can and cannot do.