Playing Every Position: Building a Data Warehouse When You're the Entire Team

How we became project manager, analyst, architect, and developer for a football talent startup that needed everything at once

The Startup With Big Ambitions and a Small Team

"We know we need a data warehouse. We just don't have the people to build it."

That's how the conversation started with a European startup revolutionizing how young football talent gets discovered and developed. Their platform tracked everything about youth players—on-field performance metrics, training attendance, academic progress, even lifestyle factors that impact athletic development. Scouts, coaches, and clubs used their analytics to identify promising talent early.

The business model was working. They had users, they had data, they had insights that genuinely helped young athletes improve. What they didn't have was infrastructure to support any of it sustainably.

Their data lived everywhere. CRM systems for managing club relationships. Spreadsheets tracking player statistics. Performance databases recording training metrics. Financial systems managing contracts and payments. Nothing connected. Every analysis required manual data gathering from multiple sources.

They knew they needed a proper data warehouse. But they were a lean startup focused on product and customer acquisition. They didn't have a data team. They didn't have spare engineering resources. They barely had budget for infrastructure projects.

What they needed wasn't just a data engineer. They needed someone who could understand the business, analyze requirements across departments, design the solution architecture, select the right tools, manage the project, and actually build the thing.

That's how we ended up playing every position.

Understanding a Business You've Never Seen Before

When you're building data infrastructure for a domain you don't understand, you can't start with technology decisions. You have to start by learning the business.

We spent the first month just talking to people. The finance team showed us how they tracked contracts, payments, and currency conversions across multiple countries. The sales team explained their process for onboarding new clubs and managing partnerships. The analytics team walked through how they evaluated player performance and generated scouting reports.

Every department had pain points. Finance couldn't reconcile payments across systems. Sales couldn't see pipeline health without manually compiling data from their CRM. The analytics team spent hours preparing reports that should have been automated. Customer support needed visibility into user activity but had no way to access that data.

The challenge wasn't just technical—it was organizational. Different departments had different priorities. Finance cared about accuracy and auditability. Sales wanted speed and visualization. Analytics needed flexibility and raw data access. Any solution had to serve all these needs without becoming a complicated mess.

We documented everything. Current systems, data sources, reporting requirements, pain points, wishlist features. We mapped data flows. We identified where information was duplicated, where it was missing, and where manual processes were bridging gaps in automation.

This discovery phase felt slow to the client. They wanted to see dashboards and reports. We had to explain that understanding the business was how we'd avoid building the wrong thing. A data warehouse that doesn't match how people actually work is just an expensive storage system that nobody uses.

The Architecture Decision That Set Everything Else

With requirements documented, we faced the classic build-or-buy decision across multiple layers of the stack.

We evaluated options methodically. Keboola versus building custom ETL pipelines. Power BI versus Tableau versus Looker. Snowflake versus BigQuery versus sticking with their existing MSSQL. Metabase for lightweight dashboards. Redash for SQL-based reporting.

The temptation with startups is to choose the coolest, most modern stack. We resisted that. Instead, we optimized for three constraints: cost (they had limited budget), skills (they had limited technical team), and time-to-value (they needed results fast).

The decision came down to Keboola and Power BI, which the company was already using in limited ways. This wasn't the sexiest choice, but it was the smart one.

Keboola gave us a managed platform for data extraction and transformation without building custom pipeline infrastructure. Power BI was already familiar to some users and integrated well with their Microsoft ecosystem. We could deliver value faster by extending tools they knew rather than introducing completely new platforms that required training.

The architecture was straightforward. Keboola would handle extraction from various sources and transformation into clean data models. Everything would land in a central warehouse structure. Power BI would sit on top for visualization and reporting. Simple, maintainable, and scalable enough for their current needs and near-future growth.

Once the client approved the approach, we could finally start building.

Starting Where It Hurt Most: Finance

We chose to tackle the finance department first because their pain was most acute and their requirements were clearest.

The core system was Pipedrive CRM, which they used not just for sales pipeline but also for contract management and financial tracking. This was unconventional—most companies use dedicated financial systems—but it was their reality. We needed to extract this data reliably and transform it into financial reporting formats.

The complexity came from currency conversions. They operated across multiple European countries with different currencies. Exchange rates fluctuated. Contracts were denominated in various currencies but reporting needed to be in Euros. Historical analysis required using exchange rates from the transaction date, not current rates.

We built currency conversion logic that pulled daily exchange rates and applied them correctly based on transaction dates. We integrated accounting books data that existed in separate systems. We created reconciliation reports that let finance verify everything balanced correctly.

The biggest challenge was building custom extractors for systems that didn't have standard connectors. Some of their financial tools had APIs that were technically available but practically difficult to work with. We wrote custom Python extractors that handled authentication quirks, rate limiting, and data format inconsistencies.

Testing was critical. Financial data has zero tolerance for errors. We validated every number, compared outputs to their manual spreadsheets, and had finance review everything before considering it production-ready. This took longer than the client initially expected, but shipping wrong financial data would have been catastrophic.

Sales: Integrating What Already Worked

After finance, we moved to the sales department. Their primary challenge wasn't building new capabilities—it was integrating their existing reports into the new infrastructure.

Sales lived in Pipedrive. They had reports and dashboards they relied on daily. They didn't want to relearn how to track pipeline, measure conversion rates, or forecast revenue. They wanted their familiar reports to just work better.

We focused on migration rather than reinvention. We replicated their existing Pipedrive reports in the new system, then enhanced them with data from other sources they couldn't access before. Pipeline reports now showed not just deal status but also customer usage data. Forecasting included historical close rates calculated from complete data rather than manual estimates.

The integration work was tedious but essential. Each report had subtle logic that wasn't documented anywhere. We had to reverse-engineer formulas, understand business rules that only existed in someone's head, and replicate everything accurately before adding enhancements.

This approach paid off. Sales adoption was immediate because their daily workflows barely changed. The reports looked familiar. The numbers matched what they expected. But now they had additional context and capabilities they didn't have before.

With finance and sales working, we had completed phase one. The infrastructure was live, departments were using it daily, and we could hand over a production system that delivered real value.

The Challenges Nobody Warns You About

The technical work was straightforward. Building data pipelines, writing transformations, creating reports—we've done that dozens of times. The real challenges were organizational and communication.

Working with the finance team was difficult. Not because they were unreasonable, but because they were extremely busy and data infrastructure wasn't their priority. Getting time on their calendars took weeks. Getting answers to technical questions about how specific calculations worked required multiple follow-ups. Validating that our implementations matched their expectations was a slow back-and-forth process.

Financial system integrations were more complex than anticipated. APIs that were supposed to be standardized had vendor-specific quirks. Data formats that should have been consistent had edge cases. Authentication mechanisms that were documented often didn't work as described. We spent more time debugging integration issues than we expected.

Project management was the hidden complexity. We were simultaneously:

• Managing stakeholder expectations across departments

• Analyzing requirements and translating them into technical specifications

• Designing architecture and making technology decisions

• Writing code and building pipelines

• Testing and validating with end users

• Documenting everything for knowledge transfer

Wearing all these hats meant constant context switching. One hour we'd be in a requirements meeting with the analytics team discussing performance metrics. The next hour we'd be debugging a Pipedrive API integration. Then we'd be updating project documentation, followed by a demo to sales showing their new reports.

The mental overhead was significant. But it also gave us control and speed. We didn't have handoffs between business analysts, architects, and developers that could introduce miscommunication. We understood requirements deeply because we'd gathered them ourselves. We made architecture decisions informed by implementation realities because we were doing the implementation.

For a lean startup project, this was exactly the right model.

What We Delivered

After several months of intensive work, we handed over a complete data infrastructure that transformed how the company operated.

Finance could finally see accurate financial data in real time. Currency conversions worked correctly. Contract tracking was automated. Reconciliation reports that used to take days of manual work now ran automatically. The CFO could answer board questions with confidence instead of caveats.

Sales had their familiar Pipedrive reports enhanced with company-wide data. Pipeline visibility improved. Forecasting became data-driven rather than gut-feel. The sales team could identify patterns in what deals closed and why, helping them prioritize better opportunities.

The foundation was in place for the analytics team to build performance tracking and scouting reports. Clean, centralized data made development dramatically faster. They could focus on deriving insights rather than fighting with data quality and access issues.

Most importantly, the company had infrastructure that could grow with them. Adding new data sources followed established patterns. Building new reports used consistent data models. The system was documented and maintainable. They weren't dependent on us—they could operate and extend it themselves.

Playing Multiple Roles: Lessons Learned

Being project manager, business analyst, architect, and developer simultaneously taught us several things.

First, deep context beats specialization in small projects. Having one person understand every layer meant decisions were better informed and communication overhead disappeared. The downside was mental load, but for a project this size with aggressive timelines, the tradeoff was worth it.

Second, starting with business understanding rather than technical architecture prevented waste. If we'd jumped straight to technology decisions, we would have built the wrong thing. The time spent learning the business paid dividends in building solutions that actually matched how people worked.

Third, managing stakeholder communication is harder than managing technology. The technical challenges were solvable with effort and skill. The organizational challenges—getting time with busy executives, aligning different department priorities, maintaining momentum when stakeholders got pulled to other fires—required different skills entirely.

Fourth, choosing familiar technology over bleeding-edge accelerated adoption. Power BI and Keboola weren't the sexiest choices, but they worked and people knew them. Introducing completely new platforms would have added training overhead and reduced adoption.

Fifth, financial data requires extra paranoia. We triple-checked everything. We validated against source systems. We had finance review before deploying to production. This felt excessive at the time but was absolutely necessary. One mistake in financial reporting could have destroyed trust in the entire system.

The Long-Term Impact

We handed over a system that worked and that the client's team could maintain and extend. But the real impact went beyond the specific dashboards and reports.

The company professionalized their operations in a way that made them more credible to investors and enterprise customers. They could show data-driven decision making. They had audit trails for financial reporting. They could answer complex questions about business performance without scrambling to compile data.

The cross-functional visibility changed how departments collaborated. Finance understood sales pipeline better. Sales understood financial constraints better. Everyone could see how their work connected to company-wide metrics. This kind of organizational alignment is hard to achieve, but shared data infrastructure enables it.

The infrastructure scaled as they grew. When they expanded to new markets, adding those data sources followed established patterns. When they needed new analytics capabilities, the foundation was ready. They didn't need another major infrastructure project—they could build incrementally on what existed.

Perhaps most valuable, they learned what good data infrastructure looked like. The team had seen the process of proper requirements analysis, thoughtful architecture decisions, and disciplined implementation. This knowledge would inform their future technology decisions as the company matured.

What We'd Do Differently

Looking back, we'd structure stakeholder engagement more formally from the start. Regular check-ins with clear agendas and documented decisions would have prevented some of the communication friction. The flexible, ad-hoc approach felt accommodating but created inefficiency.

We'd also push harder for dedicated time from key stakeholders. The finance integration took longer than necessary because we were fitting into people's spare moments. A few focused workshops would have been more efficient than months of asynchronous communication.

The phased approach worked well, but we might have tackled a smaller vertical slice across all departments first rather than completing finance entirely before moving to sales. This would have demonstrated value more broadly sooner, though it might have complicated project management.

If You're Building Without a Team

If you're running a startup without dedicated data resources and thinking "we need infrastructure but don't have people to build it," you're in good company.

Most early-stage companies face this challenge. You know data infrastructure would accelerate your business. You can see the inefficiencies from manual processes and disconnected systems. But you can't afford to hire a data team, and your engineers are focused on product development.

The good news is that modern platforms make this solvable without massive teams. You don't need a dedicated data engineering department. You can start with managed services that handle infrastructure complexity, allowing small teams to deliver significant value.

The key is finding someone who can play multiple roles effectively. Pure specialists struggle in early-stage environments where the business analyst, architect, and developer need to be the same person. Generalists who can understand business requirements, make technical decisions, and execute implementation are worth their weight in gold.

Data infrastructure should enable growth, not wait for it. When done right, it amplifies what small teams can accomplish and provides the foundation for scaling operations as the business grows.

Project Details:

• Duration: 6 months phase one (finance + sales)

• Technologies: Keboola, Power BI, Pipedrive, Custom Python Extractors, MSSQL

• Industry: Sports Tech / Talent Management

• Team: 1 senior data engineer (all roles)

• Engagement: Fixed project with multiple phases

Key Roles Played:

• Project Manager: stakeholder coordination, timeline management

• Business Analyst: requirements gathering, process mapping

• Solutions Architect: technology selection, infrastructure design

• Developer: ETL development, custom extractors, dashboard building

• QA/Tester: validation with end users, data quality verification

Outcomes:

• Automated financial reporting with multi-currency support

• Integrated sales pipeline visibility across systems

• Foundation for player analytics and scouting reports

• Self-service reporting for business users

• Scalable infrastructure ready for company growth

Building something ambitious with limited resources? Sometimes you need someone who can do it all—understand the business, design the solution, and build it. We've done this enough times to make it work.