Executive Summary

Working with freelance marketing professionals & agencies involves more than simply agreeing on a project and delivering creative work. Businesses and freelancers/agencies need to communicate regularly, share materials, discuss revisions, review deliverables, and keep track of ongoing activities. As these collaborations grow, managing everything can become increasingly difficult.

Much of this work is currently handled through a combination of email, messaging applications, cloud storage, and project management tools. While these tools serve their individual purposes, switching between them makes it harder to keep track of information and maintain a clear overview of the collaboration.

Reklab aims to simplify this process by bringing freelance marketers, agencies and their clients together in one shared workspace. By centralising campaign information, communication, feedback, approvals, and reporting, Reklab aims to reduce administrative work, improve transparency, and allow marketers to focus more on delivering value to their clients.

Interviews with marketing professionals highlighted challenges related to fragmented workflows, manual reporting, and client communication. Competitor analysis revealed existing solutions addressing individual parts of these processes, while initial prototype evaluations identified opportunities to improve usability and clarify the platform's value proposition.

Reklab has developed into a prototype, but further validation is needed. This report is intended for freelance marketers and agencies managing digital advertising for clients. It presents Reklab's potential value, current development, and opportunities for improvement. The next step is pilot testing with marketers to evaluate its usefulness in real workflows.

We invite freelance marketers and agencies to explore Reklab and help shape a simpler way of working with clients.

1. Introduction

1.1 Background: Digital Advertising and Client Management

Platforms such as Meta, Google and TikTok have made paid advertising easier for small companies, but using them well requires knowledge of planning, audiences, creatives, budgets, platform settings and analyzing performance. Paid advertising includes search, social media and ecommerce advertising, along with creative production, attribution, reporting and client management. Advertising platforms run the campaigns, brands set the budget and pay, freelance marketers and agencies manage them, and ecommerce platforms such as Shopify help track sales data and products.

A typical client relationship involves agreeing on goals and budgets, getting account access, collecting material, getting ads approved, running campaigns, explaining results and invoicing. These steps are spread across ad platforms and tools such as email, advertising platforms, WhatsApp, Notion and Google Drive, which makes access, approvals and decisions hard to track. Industry data supports this. Basis Technologies (2026) found that inefficient processes were a major challenge for agencies, and 54% reported more strained client relationships. Upwork (2026) lists campaign management among the most in-demand marketing skills.

1.2 Introducing Reklab

The idea came from a team member who had started working as a freelance marketer and experienced delays in client communication and saw how complex the platforms can be for a starter. This made us come up with the question of how clients with less knowledge understand the work and field. Since one experience cannot represent an industry, we used it as the starting point for a pre-study. Our first concept, Reklab, was a shared workspace covering onboarding, access, campaigns, approvals, reporting and invoicing. We then began the pre-study to find out if such a platform would provide real value.

1.3 Project Objectives and Report Purpose

The pre-study aimed to reduce uncertainty around the concept by asking: How can Reklab simplify client collaboration and advertising management for freelance marketers and agencies? We examined users and workflows (design), competitors and differentiation (business), and platform connections and feasibility (technology). The findings narrowed the scope and guided the prototype. Five research questions guided the work:

RQ1: What challenges do freelance marketers and small agencies experience when managing advertising campaigns and communicating with their clients?

RQ2: What challenges do new brand owners experience when working with freelance marketers or managing digital advertising themselves?

RQ3: How does existing research address communication, feedback, approvals and decision-making between marketers and their clients, and what gaps remain?

RQ4: How do larger marketing agencies work with young entrepreneurs and start-ups, and which of their practices could be useful for smaller agencies and freelancers?

RQ5: How do existing competing solutions support advertising management and client collaboration, and where are there opportunities for Reklab to provide different value?

2. The Problem & Market Opportunity

The main challenge lies not in managing advertising campaigns themselves, but in the processes surrounding them. Inefficiencies in coordination, information sharing and decision-making can create unnecessary work, delays and misunderstandings between marketers and their clients.

Our research highlights opportunities to improve these processes. This section examines the problem from business, design and technical perspectives, identifying where the greatest challenges arise and where improvements could create meaningful value.

2.1 Current Workflows and Challenges

Managing digital advertising on behalf of a client requires coordination between two parties with different roles, expertise and responsibilities. The marketer is responsible for activities such as campaign setup, optimization and performance analysis, while the client provides business knowledge, advertising material, access to relevant systems, feedback and decisions concerning areas such as creatives and budgets.

The project addresses the challenge of coordinating these activities and decisions across the marketer and client relationship. In particular, it focuses on the workflow surrounding the advertising campaign rather than advertising optimization alone: onboarding and access, exchange of information and material, feedback and approvals, communication of performance, and decisions about subsequent actions.

Based on our pre-study and interviews with marketing professionals (Phase 3), we identified a typical workflow: client onboarding → account access → campaign preparation → approvals → performance reporting → ongoing communication.

The process begins with agreeing on objectives and budgets, followed by gaining access to advertising accounts such as Meta and Google Ads. Marketers then collect campaign materials, create advertisements and coordinate client feedback before launching campaigns.

Our interviews revealed that these activities are often distributed across tools such as email, Slack, Figma and advertising platforms. One agency professional described manually transferring performance data into PowerPoint reports, while another highlighted difficulties obtaining access to client systems. Reporting also involves translating campaign metrics into insights and recommendations that clients can understand.

These findings illustrate how coordination and administrative tasks extend throughout the advertising workflow, although further validation among freelance marketers is needed.

The project does not assume that this requires an all-in-one advertising platform. A central part of the investigation is determining which parts of the workflow should be supported, how they relate to existing systems, and where a digital solution could provide meaningful value without unnecessarily adding another tool to the workflow.

2.2 Key Problems Identified

Our interviews and literature review identified five main challenges:

1. Fragmented workflows: Information and communication are spread across multiple tools, creating duplicated work (Interviews I1–I3).

2. Time-consuming reporting: Manually collecting and presenting campaign data reduces time available for optimization (I1).

3. Complicated account access: Obtaining client permissions can delay campaign setup (I1–I3).

4. Unclear expectations: Different responsibilities and scattered feedback complicate collaboration (Literature review, RQ3).

5. Communicating business value: Clients need actionable insights rather than isolated performance metrics (I1–I2).

These findings align with Basis Technologies (2026), which identifies inefficient processes and strained client relationships as industry challenges.

2.3 Target Customer

Reklab’s primary customer is independent freelance marketers and marketing agencies who manage paid advertising for several brands, especially ecommerce. This group is particularly relevant because, unlike larger agencies, they rarely have established processes, account managers or reporting tools, so the coordination work falls on one person. Ecommerce brands also depend on connecting ad results to actual sales, which makes account access to both ad platforms and stores such as Shopify a central part of the work. Demand for freelance advertising skills is also growing (Upwork, 2026).

We identified two groups:

• Paying customer: the freelance marketer or agency, who pays a subscription to use Reklab with their clients.
• Secondary user: the marketer’s client(s), mainly small and growing ecommerce brands. They use Reklab for free to approve ads, follow results and share material, and they often have limited advertising knowledge.

2.4 Market Opportunity

The problems we described in Section 2.2 are not caused by a lack of tools. Our competitor analysis identified around 20 relevant solutions (Section 6.1), but almost all of them support only one step of the workflow, such as account access, creative approval or reporting. A freelance marketer who wants to cover the whole client relationship therefore has to combine several subscriptions. The client still has to follow the work across many places, which is the kind of fragmentation that interviewees described (I1-I3). Most of these tools are also built for the marketer, with the client as a passive receiver of links or reports rather than an active participant.

Tools that cover more of the workflow mostly focus on campaign automation and AI-driven optimization rather than on the collaboration between marketer and client. Within our specific niche, a shared workspace for freelance marketers and their clients, we managed to only find one close competitor, “Plai”. They position themselves as an AI campaign management platform. We were unfortunately never able to evaluate their product in practice as our requests for a demo as a potential customer went unanswered. The lack of responses and overall look of their website also suggests that they would not be that much of a threat to us as a competitor.

There are clear signs of this industry growing and the role of a “performance marketer” is a relatively new concept that has recently seen a growing trend in the amount of companies who advertise such roles for hiring. Agencies report more strained client relationships and too many tools (Basis Technologies, 2026), and demand for freelance advertising skills is increasing (Upwork, 2026). Together all of this point to an opportunity between the advertising platforms and single purpose tools, which would be a simple shared space for access, overview, reporting and decisions.

2.5 Delimitations

The project does not aim to develop a replacement for established advertising platforms such as Meta Ads Manager or Google Ads. Campaign infrastructure and advertising delivery remain within the existing advertising platforms, while the project investigates functionality surrounding or connecting to them.

Large advertising agencies and enterprise marketing departments are not the primary target group. They may be studied to understand established practices, but the intended context is freelancers, small-medium-sized agencies and smaller clients.

The project does not attempt to solve digital marketing in general. Activities such as organic social media management, search-engine optimisation, general customer relationship management and broad project management are outside the main scope unless they directly affect the investigated advertising workflow.

Cross-platform marketing attribution may influence how campaign performance is understood but is not treated as a problem that the project aims to technically solve.

AI is considered a potential technology for supporting specific functions, rather than a goal of the project itself. Whether AI is included, and for which purposes, should depend on the needs identified during the project.

3. The Reklab Solution

3.1 Value Proposition

Reklab helps freelance marketers spend less time chasing access, approvals and reports, and more time improving their clients’ results.

Figure 1 shows Reklab’s value proposition using the Value Proposition Canvas. The right side describes the freelance marketer: the jobs they need to do, the pains that slow them down, and the gains they want. The left side shows how Reklab responds to these.

The strongest fit is between the main pains we found in the pre-study and Reklab’s core features. Slow account access is met by a single access checklist. Manual reporting is met by reports built from data already in Reklab. Scattered feedback is met by keeping approvals and decisions in one place. The marketer saves time, and the client gets a clearer picture of what they are paying for, which builds trust on both sides.

Figure 1: Value Proposition Canvas for Reklab.

3.2 Core Features

Reklab’s features were chosen to address the main problems found in the pre-study (Section 2.2). Table 1 links each feature to the problem it solves and the value it is meant to create.

Table 1: Core features, customer problems and the features intended value.

Account access and reporting form the core of Reklab, since interviewees described them as the most time-consuming parts of client work. Approvals and the shared workspace support the collaboration around them. Invoicing and payments exist in the prototype but are treated as secondary features.

3.3 User Journey

To show how Reklab could be used in practice, we created a storyboard that follows two people: a young freelance marketer who wants to start running ads for brands, and a small ecommerce brand owner who finds advertising platforms hard to understand (Figure 2). The same story is also told in a short video.

Figure 2: Storyboard showing the marketer’s and the client’s perspectives meeting in Reklab.

The story starts with the same problem from two sides. The marketer is unsure how to get the right access and report professionally. The brand owner does not know which accounts or permissions to give. In Reklab, a single guided access checklist connects both sides. Once access is active, the marketer sees the campaign data in one overview, and the client sees a simple summary of spend, sales and results compared with the agreed target. The story ends with both working from the same information, with less back-and-forth and more trust.

In practice a freelance marketer would repeat this for several clients. Each client has its own workspace with its own targets and access status. The marketer starts the week on the dashboard, sees which clients have pending approvals or are below target, and handles those first. During the week while running the ads the marketer can always have Reklab open to get an overview of performance. At the end of the week, they send each client a short report from the same data, without collecting screenshots from different platforms.

3.4 Technical Solution and Feasibility

Our solution aims to bring part of the advertising work, feedback/approval from clients, payment collection, and report generation into one shared workspace. From a technical perspective, this means that our platform needs two connected layers. First off is Reklab itself as a platform: user accounts, client workspaces, approvals, reports, and notifications. The second would consist of integrations with Meta Ads, Google Ads, TikTok Ads, and Shopify.

3.4.1 Overall technical structure

A suggested first setup would be a React and TypeScript web application initially created using Lovable, connected to a backend service such as Supabase. Lovable would help us build and test the first version quickly, but it should not become a permanent technology we depend on. Lovable supports two-way Git sync, so the source code can be stored in our own repository and be deployed elsewhere (Lovable, n.d.).

The interface is what marketers and clients see, the backend stores data, checks permissions, generates reports, and communicates securely with external APIs. Sensitive access tokens must stay on the server and should never be placed in browser code.

Table 2: Overall view of suggested technical structure.

3.4.2 Connecting client accounts

Clients should never have to share their login credentials with Reklab. Instead, each platform (Meta, Google, TikTok, Shopify, etc) will use an authorization process commonly based on OAuth. The client is redirected to the official provider, then signs in there, selects the relevant account and approves specific permissions. Tokens must be encrypted, renewable, and removable when a client disconnects an account.

Meta Ads

Meta’s marketing API allows us to access campaign structures, creative information, and performance results. It can also support in campaign management when the required permissions are given. Meta has different permissions such as read access and ad management, which is essentially full access (Meta, n.d-a; Meta, n.d-b). As Reklab we need to know which ad account the client owns or has shared with us and which actions the client has allowed.

Google Ads

Google Ads requires both user authorization through OAuth 2.0 and a developer token for our platform. Reporting can be read through the Google Ads API, while campaign creation and budget changes use separate update operations. Google also applies different API access levels (Google, n.d-a; Google, n.d.-b)

TikTok Ads

TikTok’s API for Business supports authorization, campaign management, creative assets, and reporting. We would need the client to approve access before it could read or manage the account. TikTok also explains that reporting data can be delayed, so the dashboard should show when information was last updated rather than presenting every value live (TikTok for Business, n.d.).

Shopify

Shopify connects advertising activity with outcomes that happen on the online store, such as orders, product catalogues, and sales. The merchant would install or authorize a Shopify app and approve only the required/agreed upon permission. Reklab could then use the GraphQL Admin API and webhooks to update the information. Shopify limits access to protected customer and historical order data, so Reklab should collect only what is necessary for reporting (Shopify, n.d.-a; Shopify, n.d.-b).

Stripe payments and invoices

Stripe can help handle invoices and payments between freelancers or agencies and their clients. This would include one time invoices and recurring payments. Because we allow users to receive payments through our platform, we would likely need Stripe Connect. Stripe would handle all the payment details, while Reklab stores the agreed fee model and displays payment status. Webhooks would notify when an invoice is paid, fails, or becomes overdue (Stripe, n.d.-a; Stripe, n.d.-b).

3.4.3 Login, roles, and client approvals

Reklab would need its own login system in addition to the external account connections. With authentication we confirm who the user is, while authorization controls what the user may see or have access to change. A marketing agency and their team members may manage multiple client accounts, campaigns, and upload creatives, while a client may approve the work and changes in budget. Supabase Auth supports common login methods and can be combined with database rules that keep one client’s data separate from another client’s data (Supabase, n.d.).

3.4.4 Reporting and data handling

All of the advertising platforms report similar measures, such as spend, impressions, clicks, and conversions, but their definitions and attribution can slightly differ depending on the platform. Shopify sales may also differ from the conversions claimed by an ad platform. We need to prioritize that the original source is visible and avoid presenting one combined number. A normalized internal structure can still make the dashboard easier to understand, as long as the platform, account, currency, reporting period, and attribution setting remain attached to each value.

Table 3: Functions, needs, and the reason they are needed.

3.4.5 AI-assisted insights

AI could help give insights into data and explain the performance in simple language, but it should not change a campaign automatically. A language model can turn verified facts into a short explanation, for example that cost per purchase increased while spending stayed similar. The marketer needs to review the text before it is sent to a client, so this should be clearly labeled that it’s provided by an AI.

The AI output can show which metrics it used and avoid claims that are not supported by any data. Personal or unnecessary client information should be removed before information is sent to an external model. If OpenAI is used, its API documentation states that API data is not used for model training by default, although retention and data control setting still need to be reviewed and noted down in our terms of service (OpenAI, n.d.).

4. Development & Validation

The project followed an exploratory, iterative and participatory process combining Design, Business and Technology perspectives. We treated our first concept as a hypothesis and narrowed it step by step through literature, interviews, competitor and technical analysis, supervision and prototype testing. The work ran from 8 September to 11 November 2026 in six phases (Table 4).

Table 4: Overview of the project process.

Phase 1 - Ideation and concept selection (8-16 September)

After presenting our backgrounds, which range from HCI and design to computer science, machine learning and business, we held a brainstorming session in FigJam. Ideas included an anti-scalping system, a sports discovery platform, a student housing app and a campaign management platform for brands and freelance marketers. Each idea was discussed in terms of users, revenue and barriers, and two were selected by vote. We also noted that our own coordination was already spread across FigJam, WhatsApp, Google Drive and Notion, which mirrored the fragmentation that the advertising idea aimed to address. At the first supervision we chose the advertising direction. The initial concept was a broad dashboard for viewing and launching campaigns on Meta, Google and TikTok. The supervisor encouraged us to study the closest competitor, Plai, and to look for points where a service could fit into existing processes rather than add a new step.

Phase 2 - Planning the pre-study (21-24 September)

We divided the pre-study into five research questions (Section 1.3), each owned by one or two members. We created a common semi-structured interview guide, recruitment material and a tracking sheet for outreach. An internal pre-study report described an assumed user journey and nine problem hypotheses, such as difficult onboarding, slow approvals and clients not understanding metrics. For the literature review, a structured Scopus search returned 100 records, of which the 15 most relevant were reviewed. Recurring themes were unclear responsibilities, reports clients cannot interpret, and trust and transparency. A first exploratory prototype was built in Lovable to make the concept concrete for the group.

Phase 3 - Empirical data collection (29 September-11 October)

We contacted around 36 people and organizations, including agencies, trade associations, a union for the self-employed and organizations for new entrepreneurs. The response rate was low, as expected, and four interviews were completed (Table 5).

Table 5: Interview participants

Interviews were recorded, transcribed and analysed using the chain problem → current solution → consequence → desired outcome → opportunity. The main findings were that reporting is manual and time-consuming, that clients need interpretation rather than raw metrics, that account access is difficult, and that numbers need targets and comparison periods. Interviewees were also sceptical of yet another all-in-one tool. In parallel, the competitor analysis mapped around 20 solutions (Section 6.1), and the technical study showed that reading performance data is far more realistic than managing campaigns (Section 3.4). Since most interviewees worked in larger organizations, the findings were treated as indications for our target group rather than proof.

Phase 4 - Reformulating the problem (7-12 October)

Supervision on the first prototype challenged the broad dashboard concept. We were advised to define roles and usage scenarios more clearly, to show results relative to a previous period, and to do one thing extremely well, possibly starting with account access. To avoid group-think, each member wrote their own problem definition before we compared them. Our perspectives pointed towards reducing communication friction between marketers and clients, with account access, understandable reporting and approvals as the core. Table 6 summarises how the concept changed.

Table 6: How the concept changed through the pre-study.

Phase 5 - Prototype iteration and evaluation (13-27 October)

The prototype was updated with quick guides and clearer separation between the agency and client roles, and a storyboard was created (Section 3.3). A pilot test on 14 October showed that the design felt professional, but that the target group and value were unclear and some pages had too much text. Task-based evaluations with six participants were done between 25 and 27 October. The method and results are presented in Sections 5.2–5.4.

Phase 6 - Consolidation and documentation (28 October-11 November)

In the final phase, we revised the prototype based on the evaluation, wrote this report and prepared the presentation, demo and project web page. Throughout the project, supervision sessions worked as checkpoints where the direction was challenged before the next phase, and meeting notes were kept so that decisions could be traced. The participatory elements and their limitations are discussed in Section 8.

5. Prototype & User Evaluation

5.1 Prototype Overview

The final prototype is an interactive web application built in Lovable. It has two separate roles: the agency view for the marketer and the client portal for the business owner. It uses fictional clients with simulated advertising data. The figures below follow one scenario, from connecting a new client to sharing a report, and show the features that address the problems described in Section 2.2.

Access and onboarding: When a marketer adds a client, Reklab creates a checklist of the accounts needed, such as Meta, Google, TikTok and Shopify, and shows the status of each request. The client gets one list of what to connect instead of separate instructions. This addresses the access problems described by interviewees (I1-I3).

Figure 3: Access selection and checklist with connection statuses.

Performance overview: The client workspace starts with a “Needs your decision” banner, followed by key figures and a spend versus revenue chart. Each result is compared with the client’s own target rather than with other clients, since interviewees stressed that numbers need context and that clients have different goals.

Figure 4: Client workspace for Nordic Apparel with decision banner and target labels.

Approvals: Ads and budget changes are sent to the client portal, where the client can approve them or request changes. Every decision is saved in an activity history, so feedback no longer gets lost across email and messaging apps.

Figure 5: Client portal showing ads waiting for approval.

Reporting: The marketer can create a report that presents results in plain language together with targets and recommended next steps. This responds to the finding that clients need interpretation and recommendations rather than raw platform metrics (I1-I2).

Figure 6: Weekly report as seen by the client.

5.2 Evaluation Method

The prototype was evaluated through task-based usability tests between 25 and 27 October, after a pilot test with an agency professional on 14 October. The aim was to see whether participants could complete common tasks, whether they understood the information shown, and which parts they found most useful.

Six participants took part, three in the agency scenario and three in the client scenario. Each role had its own scenario (described in Phase 5), and both started with the quick guide. In the agency scenario, participants reviewed a client’s results, created a client and an ad, sent it for approval, responded to client feedback, and prepared a report and an invoice. In the client scenario, participants interpreted key figures, approved one ad and requested changes to another, read a report, shared material and checked an invoice.

After each task, participants recorded whether they completed it, whether they needed help, and how they knew the action had worked. At the end, they rated five statements on a five-point Likert scale (1= strongly disagree, 5 = strongly agree). They also answered open questions about what was useful, confusing or missing. All responses were collected through Google Forms. The results are presented in the next section (Section 5.3). Task completion and Likert ratings were summarized per role. Open answers were grouped into recurring themes, which became the revision list for the final prototype (Section 5.4).

5.3 Evaluation Results

Overall, participants were positive about the concept. Both sides rated Reklab as useful and said they could imagine using it (Figure 7). Since each group only had three participants each, the averages should be read as indications rather than measurements.

Figure 7: Average ratings of the closing statements (n = 3 per role).

The clearest problem was the difference between internal and client-visible information. Agency participants rated “Clear what the client can see” at 1.7, the lowest score in the evaluation, and it was described by one as their biggest difficulty. Feedback after actions were also mixed, and one participant wrote that it was “hard to decide whether or not a button was supposed to be a button”.

Figure 8: Average ratings of how easy each task was (1 = very difficult, 5 = very easy).

Most tasks were rated as fairly easy (Figure 8). Approving ads was the easiest client task. Finding brand material (2.7) and handling notes and feedback (3.0) were the hardest. One agency participant could not find where to add a client and gave that task the lowest score possible. Another noticed that paid invoices seemed to disappear from the list.

When asked which features were most useful, participants on both sides most often pointed to the reporting and performance overview. One client participant also asked for colors to show good and bad performance. These findings formed the list of changes to the prototype in Section 5.4.

5.4 Improvements Based on Feedback

We used the problems found in the evaluation as a list of changes for the second prototype. The table below summarizes the main changes. Minor visual/other changes that did not come from feedback are not included.

User feedback	Identified problem	Design improvement	Visual change
Participants were unsure what the client could see	Internal and client-visible information looked the same	“Visible to client” / “Internal only” labels on all items, yellow internal notes, and a “Preview as client” switch
Participants were unsure whether actions had worked	Actions gave little or no feedback.	A confirmation message after every action and clearer button feedback
Paid invoices disappeared from the list	Users lost their payment history	Invoices stay visible with status filters (All, Upcoming, Paid, Payment failed), a sortable invoice table and a detail view
Participants asked for colour coding and clearer goals	Figures lacked context, so results were hard to judge	Metrics are compared with the client’s target using colour and icon labels that are readable for colour blind users
Some pages had too much text and too many steps	Important actions were hidden among secondary information	A “Needs your decision” banner at the top of the workspace, followed by key metrics, with secondary information moved further down
The target user and value were not immediately clear	New users could not quickly see who Reklab is for	Story and product demo videos on the landing page, and a welcome and summary step in the quick guide

Table 7: Improvements to the prototype based on user feedback.

6. Business Model & Competitive Positioning

Reklab enters a market with several established advertising tools. Its business potential therefore depends on offering clear value compared with existing solutions, particularly for freelance marketers and small agencies with limited resources.

6.1 Competitive Landscape

Our competitor analysis identified approximately 20 relevant solutions, divided into six categories:

Table 8: Competitive landscape and their primary focus.

The identified market gap is a simple, Swedish-friendly shared workspace for beginner freelancers and small-business clients, where both parties can manage onboarding, approve creatives and budgets, and follow campaign results together.

Most competitors focus on individual steps of this workflow. Plai is the closest competitor, offering multi-client advertising management, but its positioning emphasises AI-driven campaign management rather than collaboration between freelancers and clients.

Reklab therefore aims to differentiate itself through client collaboration and simplicity, rather than competing with established platforms on advertising automation. However, this market gap requires further validation.

6.2 Competitive Advantage

Reklab's proposed advantage is not simply combining features, but simplifying the workflow between freelancers and small-business clients.

Rather than replacing established advertising platforms, Reklab aims to connect client onboarding, account access, performance reporting and approvals in one shared workspace.

Its initial focus is independent marketers and small agencies serving smaller Swedish businesses, where a straightforward and accessible solution could be particularly valuable. However, this differentiation remains a hypothesis requiring further customer validation.

6.3 Business Model

Reklab proposes a subscription-based SaaS model targeting freelance marketers and small agencies. Marketers would pay a monthly fee based on the number of clients they manage, while their clients would access the platform for free.

A free trial would allow marketers to evaluate the platform before subscribing. This model aims to keep entry barriers low for new freelancers while allowing pricing to scale as their businesses grow.

The pricing structure and willingness to pay would need to be validated through further customer research.

6.4 Customer Value and Return on Investment

Reklab creates value by acting as a shared workspace between freelance marketers and their small-business clients, rather than another AI advertising tool. Instead of replacing Meta Ads Manager or existing invoicing systems such as Fortnox, Reklab aims to simplify the collaboration surrounding these tools.

Its value comes from connecting activities currently handled separately: account access, creative and budget approvals, client communication, and understandable performance reporting. This reduces administrative work while giving clients greater transparency and making collaboration more professional and efficient.

Illustrative ROI: A freelancer managing five clients who saves one hour per client monthly would save five hours. At an assumed hourly rate of 500 SEK, this represents 2,500 SEK in potential monthly value, potentially exceeding the subscription cost.

For beginner freelancers and small agencies in Sweden, Reklab could also support growth by making it easier to manage more clients without increasing administrative workload proportionally.

These benefits and time savings remain assumptions that require validation through real-world testing.

7. Launch Strategy & Roadmap

7.1 Initial Market and First Customer

The ideal first customer is new freelance marketers who have recently started running ads for ecommerce brands. Many of them come from online courses and communities, and have often just managed to land their first ever clients. In our eyes the ideal early adopter of our solution is at the start of their entrepreneurial journey and manages paid ads for one to five ecommerce brands, usually on Meta with the clients store on Shopify. They would have no fixed system for working with clients yet, so gaining access, reporting and asking for approval takes up a lot of their time and can become complex. The marketers want to look professional and grow their business.

The reason to focus on this group first is because this is the problem Reklab solves the best. They are still learning the platforms, and every hour that they spend on doing different types of admin work is an hour that they lose out on improving results. They are also easy to reach through the communities and courses where they learn. Most importantly, they can grow with Reklab. A freelancer who starts with two clients may manage twenty a few years later, and become a valuable customer to us long term. In the long run, our hope is that Reklab becomes the industry standard for how this target group works with clients.

7.2 Minimum Viable Product

We need to develop the smallest version of Reklab we can ship that still delivers real value needs to cover the whole workflow of how the marketers currently work. The marketer adds a client, gets access to their accounts, sees the results, shares a report and sends an invoice. If any step in this flow is missing we lose our value as a platform, because the marketers would have to go back to their old tools, and Reklab instead becomes one more place to check instead of a place to do work in.

These features must be fully functional in the MVP:

• Secure login and roles
• Client workspaces
• Access checklist/connection
• Performance overview
• Client reports
• Simple approvals
• Invoicing

7.3 Go-to-Market Strategy

Reklab plans to reach freelance marketers through four channels, chosen for where this group already spends its time.

Direct outreach: Lead generation tools such as Apollo.io can be used to find freelance marketers and small agencies that work with ecommerce brands. Personal outreach by email and LinkedIn then invite them to try Reklab. This builds on the outreach process already used in the pre-study.

Communities and course partnerships: Many new freelance marketers learn the trade through ecommerce and advertising courses and gather in Discord servers and online communities. We will join these communities and recruit users directly. We will also partner with course owners through an affiliate model, where they earn a commission on every paying user they refer. Course owners get a tool to recommend to their students, and Reklab reaches marketers at the moment they start taking on their first clients.

Building in public: One team member will document the process of building Reklab on social media. Growing a following over time makes later marketing easier and builds trust before the product is launched. This also grows a personal brand in the process.

A showcase brand: We also plan to start a small ecommerce brand and run its advertising through Reklab. This gives a real, public example of how the workflow between marketer and client works, and how a brand can scale when the marketer spends less time on admin and more on creating creatives and running ads.

Convincing the first customers: The first users will be recruited from our existing contacts and these communities, and offered a free pilot period with personal onboarding. The main selling point is time. Marketers are often paid based on performance, so time saved on access, reporting and follow-ups can go into work that grows the client’s results. When the brand scales, the marketer earns more too, which makes Reklab an investment in their own income rather than another cost.

7.4 Development Roadmap

Figure 9 shows how Reklab could be developed from late 2026 to the end of 2027. Much of the groundwork is already done. Through the pre-study we have contacted around 36 professionals and organisations, carried out interviews and user tests, and built a prototype. This means validation can start directly after the course, building on existing contacts, with the goal of confirming that freelance marketers & agencies would use and pay for Reklab.

With this foundation, we aim to have an MVP ready by the end of Q1 2027. It will cover the full core workflow: account access, Meta and Shopify data, client reports and invoicing. The MVP is then tested in a pilot with a few freelancers and their clients before pricing and outreach to freelancers and agencies are introduced. More advertising platforms and online payments are added last, once the core workflow has proven useful. Each phase depends on the results of the one before, so the timeline may shift.

Figure 9: Planned development of Reklab from Q4 2026 to Q4 2027.

7.5 Key Risks and Dependencies

Reklab has several risks and some dependencies that we have identified. The first one being that we are not yet sure if there’s a willingness to pay for our platform. New freelancers often have smaller budgets, and our pre-study did not test the pricing. We will ask about the willingness to pay in the validation phase, offer a free pilot period, and try to keep the entry price low. However, we have a strong argument, if Reklab helps a marketer keep a client or deliver better results, it pays for itself.

Marketers already use tools that they are familiar with, the interviewees were sceptical of yet another platform. Reklab therefore works beside the ad platforms rather than replacing them, the MVP would focus on the most time-consuming tasks, which is access, approvals and reporting.

Reklab also depends on external API connections from Meta, Google, TikTok and Shopify, which controls what data can be accessed. Platforms can change their rules at any time or have unexpected maintenance/downtime which negatively reflect our platform since we cannot do anything about it.

Reklab will also handle access to client accounts and business data, so if a security problem appears it could quickly destroy trust and our reputation. Building and maintaining integrations also takes time and money, we would need to find out an estimate of how much it would take to develop at MVP. Then consider applying for funding if it turns out to be too expensive for the team itself to fund Reklab.

8. Critical Discussion & Limitations

8.1 Strength of the Evidence

This pre-study helped us identify recurring problems in marketer-client collaboration and decide what to address in the development of the prototype. The literature review focused on agency-client relationships but with more focus on the SME-scale segment of the sector, it was not directly applicable by itself. The interviews mainly provided insight from people working in agencies or organisations connected to businesses (Table 5). These sources gave us a basis for considering similar problems in freelance work. As our initial setting described the same or similar patterns for newer freelancers and their small-business clients from personal experiences, it is not far-fetched to say these troubles span multiple scales of the industry and its actors. However, we acknowledge that these claims need to and will continue to be challenged and tested during our continued work.

Fragmented tools and difficulties obtaining access to client accounts came up in three interviews (I1-I3) and the time spent on reports was raised in one interview (I1). This again strengthened our reason to investigate the initial claims of manual reporting being a burden on freelance marketers who handle reporting alongside other campaign work. We received broader support for the need to make reports easier for clients to interpret, as this was something shown directly in both literature and during the interviews. In total, this was enough reasons to make the report builder feature in the prototype, and consider it a core part of the solution proposition.

The usability evaluation highlighted reporting and the performance overview as useful from participants in both scenarios. It also revealed uncertainties about what the client could see when acting as the marketer. It received a low enough score to give us concrete reasons to make the boundary between internal and shared information clearer, for example, a feature in the marketer view where you can preview the client’s view by flicking a switch. This also relates to questions raised in the literature reviewed about how transparency is needed.

The six participants worked through predefined tasks with simulated campaign data. Their feedback helped us identify where the prototype needed revision and brought to attention matters that we might have overlooked. This helps us feel confident in the basis of the prototype but also serves as a reminder to never stop questioning our own assumptions during the future of this project, especially during future testing with real freelancers and their clients on real situations and real data.

8.2 Lessons from the Development Process

Our group had experience in HCI, design, computer science, machine learning and business, and we all were able to bring different perspectives into the project in useful ways. The technical research allowed us to keep our ideas realistic, while researching the business side we could figure out who would actually pay for Reklab and what our strategy could look like. We had some difficulties staying aligned on the problem when we divided the work, but solved this by each writing our own problem definitions and later comparing and combining these into a definition that everyone was on board with. Our own communication also ended up very scattered, which can be seen as quite ironic looking at the solution we came up with.

By bringing the pre-study findings and the technical assessment together we moved away from trying to solve everything and instead towards the parts of the workflow that marketers and clients actually need to work together on. The prototype could have followed these decisions more closely. At times the gaps between reviews were a bit too long so that there was much to discuss in one meeting.

Recruitment of participants taught us to look for people with the exact workflow we want to understand. Many early contacts weren’t entirely in the exact role we were looking for, and some more professionals worked in quite different and bigger scale settings. By involving a freelancer and a client who already work together from the start would have let us compare their views of the same tasks and confirm where the friction actually occurs. It would have been interesting to see how it could have shaped the project at an earlier stage.

9. Conclusion

Reklab has the potential to address a real challenge for businesses and freelance marketing professionals by bringing their collaboration activities together in one shared workspace. Throughout this project, we have developed the platform, explored its functionality, and gained initial insights into how potential users might interact with it.

However, a working product alone does not guarantee a successful business. The next step is to validate the market, identify the customers who would benefit most from Reklab, and understand whether they are willing to adopt and pay for the solution. This will require gathering feedback from more users, refining the platform, and testing it with a small group of early customers.

Ultimately, the goal is to turn Reklab from a developed concept into a sustainable business by creating a product that genuinely simplifies collaboration and becomes valuable enough for businesses and freelancers/agencies to integrate into their everyday work.

References

Basis Technologies. (2026). 2026 advertising agency report. https://basis.com/reports/2026-advertising-agency-report

Google. (n.d.-a). Google Ads API access levels. https://developers.google.com/google-ads/api/docs/api-policy/access-levels

Google. (n.d.-b). OAuth 2.0 for the Google Ads API. https://developers.google.com/google-ads/api/docs/oauth/overview

Lovable. (n.d.). Git synchronization overview. https://docs.lovable.dev/integrations/git-sync-overview

Meta. (n.d.-a). Marketing API use cases. https://developers.facebook.com/documentation/development/create-an-app/marketing-api-use-cases

Meta. (n.d.-b). Permissions reference. https://developers.facebook.com/documentation/development/permissions

OpenAI. (n.d.). Data controls in the OpenAI platform. https://platform.openai.com/docs/models/default-usage-policies-by-endpoint

Shopify. (n.d.-a). App authentication and authorization. https://shopify.dev/docs/apps/build/authentication-authorization

Shopify. (n.d.-b). Webhook subscriptions. https://shopify.dev/docs/apps/build/webhooks/subscribe

Stripe. (n.d.-a). Build a SaaS platform with Connect. https://docs.stripe.com/connect/enable-payment-acceptance-guide

Stripe. (n.d.-b). Invoices API. https://docs.stripe.com/api/invoices

Supabase. (n.d.). Auth documentation. https://supabase.com/docs/guides/auth

TikTok for Business. (n.d.). Marketing API documentation. https://business-api.tiktok.com/portal

Upwork. (2026). Upwork’s in-demand skills 2026: Demand for top AI skills more than doubles as AI is embedded into everyday work [Press release]. https://www.upwork.com/press/releases/upworks-in-demand-skills-2026-demand-for-top-ai-skills-more-than-doubles-as-ai-is-embedded-into-everyday-work