Work/Education
Fikazon Institute of Technology
People who have never written code build an application, launch it and defend it.
LiveLive and open for enrolment, with a new cohort each month.
Web
Training institute and cohort platform
The problem
“I keep describing an app I want. How do I actually build it?”
Plenty of people have a clear idea for an application and no route to making it. AI coding tools can now write most of the code, but a beginner still gets stuck: on files and folders, on a blank page caused by one error, on an assistant that rewrites what was already working, and on getting the thing onto a public address. A course that ends in slides proves nothing. And a certificate from a new institute means little unless anyone can check it and open the work behind it.
Who had it
- People with an idea and no coding backgroundA route from a description to a working application they can show.
- Employers and clientsProof they can open: the certificate checked online, and the project itself.
- The instituteTo run a new cohort every month without re-entering dates, prices or seats by hand.
What the answer had to survive
- Participants start with no programming background.
- Each cohort has a fixed number of seats, held by payment.
- Learner projects are untrusted code, hosted on the institute's own domain.
- The site runs on ordinary shared hosting, with no build step.
- A certificate must not claim more than its holder did.
What we built
One method, five kinds of application, and a public record of what each person built.
Each cohort is a month of live evening sessions. A participant chooses a web application, a mobile app, a game, a desktop program or an AI application. They write its specification, build it with AI coding tools, launch it publicly, show it working on demo day and defend it before a panel. The platform takes the booking and the payment, gives each participant a portal for their schedule and submissions, publishes approved projects in a sandbox, and issues a certificate with a serial that anyone can check.
5kinds of application a participant can choose to build
12evening sessions in each cohort, ending in a demo and a defence
4cohort months open for booking at once, kept current by the system
3separate protections between learner code and the rest of the site
0dates typed into the code. Every schedule is worked out from the calendar
What it does
The programme
- Five destinations, one methodWeb application, mobile app, game, desktop program or AI application. The teaching is the same; what changes is where the project ends up.
- Specification firstThe first week ends with a written specification a machine can build from, and a working set of tools.
- Built with AI, and understoodParticipants build with AI coding tools, and learn to read an error and narrow a problem instead of guessing.
- Launch, demo and defenceThe last week is a public launch, a live demo and a defence before a panel.
Booking and payment
- Pick a monthThe site always shows the current cohort and the next three, each with its own dates and seats left.
- Seats held by paymentA seat is reserved when the payment has been confirmed directly with the payment provider.
- Schedules worked out, not typed inSession dates, the closing date, demo day and the defence are calculated from the calendar for every cohort.
- Unfinished bookings followed upSomeone who starts a booking and stops is kept on a follow-up list for the office.
Portal and projects
- Participant portalSchedule, demo slot, profile and project submission in one place.
- Review and feedbackStaff review each submission, then ask for changes or approve it.
- Published projectsAn approved project is published at its own address under the institute's domain, marked with its author's learner reference.
- AnnouncementsStaff write to a whole cohort from templates, and can send to themselves first.
Certificates
- A serial anyone can checkEach certificate carries a serial and a QR code that lead to a public verification page.
- The project is on the certificateThe certificate names the verified project address, so the work can be opened.
- No overclaimingThe wording says what the holder did: documented, built, launched, presented and defended a project.
- PrintableCertificates print on a landscape sheet straight from the browser.
A day with it
- 1
Choose a month and a build
A visitor picks a cohort and the kind of application they want to build.
- 2
Reserve the seat
They register and pay. The confirmation shows their first session and their demo slot.
- 3
Write the specification
Week one ends with a written specification and a working toolchain.
- 4
Build it
By the end of week two the project runs and does one real thing from start to finish.
- 5
Make it real and launch
The hard feature, the look, then a public launch.
- 6
Demo, defend, certificate
They show it working, answer the panel's questions and receive a certificate that can be checked online.
How it works inside
A plain PHP site with no framework and no build step, on ordinary shared hosting. One engine works out every cohort's dates from the calendar and keeps the coming months open for booking. Learner projects are served through a single script that sandboxes them in the browser, and uploaded files can never run on the server.
Cut the network to see what this system does without it.This one lives on the internet, so it waits, like any website. Its staying power is on our side: backups, health checks and tested recovery.
On the device
- Visitor or participant browserBooks a seat, uses the portal, opens projects.
Our cloud
- Public site and bookingMonths, kinds of build, curriculum, registration.
- Participant portalSchedule, demo slot, project submission.
- Staff back officeParticipants, follow-ups, reviews, certificates.
- Cohort engineWorks out each month's sessions, seats and closing date.
- Project sandboxServes each learner project with browser sandboxing.
- Certificate verificationA public page for any certificate serial.
- MySQL databaseCohorts, participants, projects, certificates.
- Uploads folderLearner files. Nothing in it can execute.
Outside services
- PaystackPayments, confirmed directly.
- Email and SMSWelcome, schedule and announcements.
Every part and every link, as text
- Visitor or participant browser — Books a seat, uses the portal, opens projects. (on the device)
- Public site and booking — Months, kinds of build, curriculum, registration. (our cloud)
- Participant portal — Schedule, demo slot, project submission. (our cloud)
- Staff back office — Participants, follow-ups, reviews, certificates. (our cloud)
- Cohort engine — Works out each month's sessions, seats and closing date. (our cloud)
- Project sandbox — Serves each learner project with browser sandboxing. (our cloud)
- Certificate verification — A public page for any certificate serial. (our cloud)
- MySQL database — Cohorts, participants, projects, certificates. (our cloud)
- Uploads folder — Learner files. Nothing in it can execute. (our cloud)
- Paystack — Payments, confirmed directly. (outside services)
- Email and SMS — Welcome, schedule and announcements. (outside services)
- Visitor or participant browser → Public site and booking: Picks a month, registers (needs internet)
- Public site and booking → Cohort engine: Asks which cohorts are open (needs internet)
- Cohort engine → MySQL database: Creates and refreshes cohorts (needs internet)
- Public site and booking → Paystack: Takes and confirms payment (needs internet)
- Public site and booking → Email and SMS: Sends welcome and schedule (needs internet)
- Visitor or participant browser → Participant portal: Signs in, submits a project (needs internet)
- Participant portal → Uploads folder: Stores submitted files (needs internet)
- Staff back office → MySQL database: Reviews, issues certificates (needs internet)
- Staff back office → Project sandbox: Publishes approved projects (needs internet)
- Project sandbox → Uploads folder: Reads published files (needs internet)
- Visitor or participant browser → Project sandbox: Opens a learner project (needs internet)
- Visitor or participant browser → Certificate verification: Checks a certificate serial (needs internet)
- Certificate verification → MySQL database: Looks up the serial (needs internet)
The hard parts
Other people's code on our own domain
- The situation
- Every participant publishes a project, and each one is a page of HTML and JavaScript written by a beginner with an AI tool. It is served from the same domain as the portal and the back office.
- What we did
- Three protections stand between that code and everything else. Uploaded files cannot execute on the server. Published files cannot be reached directly. One script serves every project inside a browser sandbox, so its JavaScript runs but cannot read the site's cookies or storage. Before a link is shared, publishing reports anything worth a second look, such as a form that posts elsewhere.
- The lesson
- Treat every upload as hostile, even when it comes from your own students.
A cohort every month, with nothing typed in
- The situation
- The first cohort was set up by hand: one record, one set of dates, and wording fixed in the emails and pages. A monthly programme could not be run that way.
- What we did
- An engine now works out each cohort from the calendar: when it starts, every session, demo day, the defence and the day booking closes. It keeps the coming months open, never rewrites a cohort that has started, and applies a price change only to cohorts that are not yet running.
- The lesson
- If something repeats every month, the calendar should do the work, not a person.
A site that still renders through a half-finished update
- The situation
- Updates reach shared hosting as uploaded files and as database changes run by hand, so for a while the code and the database can disagree. An early update failed for exactly that reason.
- What we did
- Every use of a newer database column is now checked first. If the column is not there yet, the page still renders with what it has. A check page compares every uploaded file with the release, so a stale file is found in seconds.
- The lesson
- Degrade, never fail outright.
A certificate that does not overclaim
- The situation
- A certificate from a new institute is only worth something if it can be checked, and if it says exactly what its holder did.
- What we did
- Each certificate carries a serial and a QR code that lead to a public verification page, and it names the project's address. The wording states that the holder documented, built with AI assistance, launched, presented and defended an original project. It does not call them a professional engineer, and it states that the institute is independent of every AI provider.
- The lesson
- A credential earns trust by claiming less and proving more.
The stack
- Apps
- Plain PHP, no frameworkHand-written CSS and JavaScript
- Data
- MySQLPrepared statements throughout
- Infrastructure
- Shared cPanel hostingApache rewrites
- Services
- PaystackAmazon SESTermii SMS
- Testing
- Syntax check of every shipped fileChecksum comparison after upload
How it came together
- 1The method setSpecify, build, launch, present and defend: one method for every participant.
- 2The platform builtBooking, payment, portal, project hosting, certificates and verification.
- 3Opened to five kinds of applicationThe programme widened from websites to mobile apps, games, desktop programs and AI applications.
- 4Monthly cohortsThe cohort engine replaced hand-set dates, and the site began offering the coming months.