When the first 247-course project arrived, the e-learning vertical at ConsultBae consisted of two people. There was no production team, no established sourcing pipeline for subject matter experts, no documented process for onboarding contributors at volume, no prior experience of managing a project at this scale in this domain. There was a client who needed courses built, a two-week window to begin submitting profiles, and the same operational instinct that had served the AI data and recruitment work: figure out what needs to happen, build the process as you go, and deliver.
Six months later, the project was complete. One hundred contributors had been coordinated through the full production lifecycle. The client had received course after course on the schedule agreed. Both people who ran the project were simultaneously managing other AI data work, hiring new people, and building the documentation that would eventually allow someone other than themselves to run the next project.
The story of how that happened is not a story about exceptional resources or a uniquely favourable situation. It is a story about what operational resilience actually requires when you do not have the luxury of building infrastructure before you need it.
What the Project Actually Asked For
The brief was to source and manage subject matter experts for 247 certification courses. Each course needed a practitioner with specific, recent hands-on experience in the tool or skill being taught. Each expert needed to be vetted for communication clarity and availability, onboarded through an agreement process, introduced to the client's production team, and managed through the duration of their contribution, which in some cases ran for weeks. The client's internal production infrastructure handled the content design and platform publishing. The capacity partner's job was to ensure the right people were available, engaged, and performing throughout.
This is not a simple task at any scale. At 247 courses simultaneously, with a client expecting a steady flow of vetted profiles rather than a single batch delivery, it requires a sourcing system that is continuously running, a screening process that is rapid and accurate, and a contributor management layer that can track the status of dozens of active engagements at any given time without losing the thread on any of them.
None of that infrastructure existed at the start of the project. It was built, tested, adjusted, and rebuilt while the project was already running.
What It Meant to Run It With Two People
Running a project of this scope with two people means that every function, sourcing, vetting, onboarding, contributor communication, client liaison, payment management, and quality monitoring, is done by two people. There is no handoff. There is no specialist for each stage. There is whoever is less occupied at any given moment, applied to whatever is most urgent.
This is both a constraint and, in retrospect, an accelerated learning environment. When you cannot divide the work into functional lanes, you develop a complete picture of the entire production cycle faster than you would if you only ever saw one part of it. The person who is vetting a candidate in the morning and managing a contributor dispute in the afternoon and processing invoices in the evening develops an understanding of how these stages connect and where the failures in one stage propagate into problems in the next. That understanding is what eventually produces good process documentation, because it comes from having lived the full chain rather than from studying it theoretically.
The constraint also forces prioritisation in a way that a larger team does not. With two people, you cannot do everything adequately. You have to decide what must be done excellently, what can be done to a minimum standard, and what can be deferred. Making those decisions under live project pressure is a different skill from making them in a planning session, and it is the skill that allows a small team to operate at a throughput that should theoretically require a much larger one.
"It was just me and one other person. We hired 100 people and coordinated with them through and through for six months, while simultaneously working on other AI data projects and building the vertical from scratch. The execution surprised even me."
How Coordination at That Scale Works Without a Team
Coordinating a hundred contributors across a six-month project without a dedicated team is primarily a communication and tracking problem. Each contributor is at a different stage of the production lifecycle at any given moment. Some have just been onboarded and are beginning their first deliverable. Some have submitted work that is under review. Some have completed their engagement and are waiting for payment. Some have gone quiet and need follow-up. Keeping these threads from tangling requires a system, however simple, that makes the status of every active engagement visible without requiring the person managing it to hold it all in memory.
In the absence of a purpose-built project management tool calibrated to this specific workflow, a combination of structured spreadsheet tracking, templated communication sequences, and disciplined follow-up cadences carried the coordination work. Templates that could be customised quickly for each contributor's specific situation reduced the time cost of each individual communication. A daily review of the full contributor list, which took perhaps twenty minutes, prevented the quiet attrition of contributors who had stopped responding from going unnoticed until it became a delivery problem.
What the two-person model taught about coordination is that the overhead of tracking is not proportional to the number of people being tracked, if the system is designed correctly. A well-structured tracking system for a hundred contributors is not fifty times harder to maintain than one for two contributors. The structure that works for two scales to a hundred with the same daily investment, as long as the system is built to be maintained rather than built to impress.
What Broke and How It Was Recovered
Things broke. Acknowledging this is important because the narrative of a project that succeeded does not usefully describe how projects actually work if it omits the failures that were absorbed along the way.
Contributors who had been vetted and onboarded went quiet. Some had scheduling conflicts that emerged after onboarding. Some found the workload higher than anticipated once they saw the actual brief. Some simply stopped responding. Each of these departures required the same response: go to the backup pool, restart the onboarding for the replacement, communicate the delay to the client without attributing blame, and manage the timeline adjustment. None of this was elegant. All of it was manageable because the backup pool had been built into the sourcing approach from the beginning, rather than being sourced reactively when a gap appeared.
Client brief clarifications arrived mid-project that required updating the instructions for contributors who were already partially through their deliverables. Some of these updates were minor. A few required contributors to redo work that had already been submitted. Managing these moments required transparent communication: telling the contributor clearly what had changed, why it had changed, and what the revised expectation was, without framing the change in a way that made the contributor feel their previous work had been wasted or their time disrespected.
The recoveries were not always smooth. The lesson from the ones that went badly is that the longer a problem is held before being communicated to the relevant parties, the more expensive it becomes. A contributor who is told immediately that their submission needs to be revised in a specific way will usually revise it. A contributor who is told three weeks later, after the problem has grown into a delivery gap, will often not be available to revise it at all.
What This Kind of Project Does to Your Operational Instincts
The experience of running a large project under genuine resource constraint produces a specific quality of operational judgment that more comfortable project environments do not. It is the judgment that comes from having seen every failure mode in real time, having had to fix each one without the option of escalating to a larger team, and having built the process that prevents the next occurrence while the current one is still being managed.
The process documentation that now allows the e-learning vertical to run multiple large projects simultaneously was written by someone who had made every mistake it documents. That is why it works. It is not a theoretical best practice derived from external frameworks. It is a record of what went wrong and what solved it, written at the point when the solution was still fresh enough to describe accurately.
Backup contributors built into the sourcing model from the start. The assumption that attrition would occur, not might occur, meant the replacement pipeline was ready before it was needed. Every gap was filled from a pool that already existed rather than from a search that had to begin after the gap appeared.
Communication templates that could be personalised quickly. The overhead of communicating individually with a hundred contributors would have been unmanageable without a structured communication system. Templates reduced each communication to a personalisation exercise rather than a composition exercise, which preserved the time and attention for the decisions that required genuine judgment.
A daily tracking review that caught problems early. Twenty minutes each morning reviewing the full contributor status list was the operational habit that prevented small problems from becoming large ones. Contributors who had gone quiet were identified and followed up within a day rather than discovered as gaps three weeks later.
The two-person, 247-course project is not a model to be replicated. It was a product of circumstances: a large project arriving before the team existed to support it, managed by people who had the operational instinct to build the infrastructure while using it. What it produced was not just a delivered project but the institutional knowledge of how to deliver it, documented well enough to be handed to the team that was hired afterward. That documentation is what allows the vertical to operate now at a scale and quality that would have been impossible for two people to sustain alone.
Need an E-Learning Capacity Partner With Real Production Experience?
ConsultBae manages subject matter expert sourcing, contributor coordination, and full production lifecycle management for e-learning platforms. Built from operational experience, not theoretical frameworks.
Talk to Our E-Learning Team
