Case Study: Helping a Marketing Company to Streamline Business by Developing a Back-Office Custom Ads Dashboard

In this blog, we will discuss our Case Study on Helping a Marketing Company to Streamline Business by Developing a Back-Office Custom Ads Dashboard.

There is no denying that all aspect of software development holds substantial rewards for those that get it right.

Certain startups and enterprise companies are afraid to outsource their software development – they fear losing their intellectual property and failing the project altogether. Are these fears reasonable?

In this article, we‘ll share some effective strategies and approaches for business growth and optimization through smart software development.

This case is based on cooperation between DevTeam.Space and Leadsmarket.com – one of the market leaders in pay-per-lead marketing solutions in the United States.

As a result, we‘ve helped Leadsmarket to streamline the business and quickly develop a back-office custom dashboard for internal management of pay-per-click advertisements which have later been used for the development of the client-facing product.

The Project Snapshot

Before we take a deep dive, here is Leadsmarket‘s project snapshot and a reference from their CTO: “They deliver what they promise.”
An independent review score: ★ ★ ★ ★ ★

– Quality:5.0
– Schedule: 5.0
– Cost: 4.5
– Willingness to refer: 5.0

Customer Feedback Summary: DevTeam.Space’s role within the development team ensured that the dashboard build could take place much more quickly and efficiently than if we were to do it on our own. They managed the project very well, working directly with our internal software development team, and delivered exactly what we were expecting from them on time.

We‘ll also share some examples of why companies fail to succeed with remote software development.

Project Start

As with any rapidly growing business, Leadsmarket has faced the issue of limited human resources to achieve the desired speed in developing and implementing software solutions for its new business department. When they reached out to us:

• They had already delayed the product development for 3 months.
• They didn‘t have clear product specifications and API documentation.

Important! To build a successful product you should have a clear goal (ideally if it’s tightened to your business goal). Leadsmarket‘s product team had the following goal:
“To build an internal management dashboard for the PPC ads management website within five weeks.”

How to Choose the Right Tech Stack

In this case, Leadsmarket already had a solid base with the .NET tech stack so we didn‘t have to advise them on that point. However, for those reading this case study, it might be an important topic.

Get a complimentary discovery call and a free ballpark estimate for your project

Get Started

Trusted by 100x of startups and companies like

One of the most important questions in building web, mobile or any other software solutions is to choose the right tech stack. There are several aspects to think about when making this decision:

1. Company‘s current product tech stack.
2. Human resources market trends.
3. Cost of development.
4. Product security, scalability, and speed priorities.

Current company‘s product tech stack

If your company‘s main product tech stack is MEAN (MongoDB, Express, AngularJS, and Node.js) then you probably should consider continuing with it, unless you see a trend that indicates this tech stack is in decline and in five years‘ time there will be almost no developers to hire, or that the tech stack is losing the community support. So, it‘s important to build your product on a well-supported tech stack.

HR market trends

In this case, Leadsmarket has built all its products on .NET tech stack. Also, this tech stack is well supported, and the community is strong, so we didn‘t recommend any changes.

The .NET human resources market trend looks strong and solid over the next 5 years. The Leadsmarket headquarters is located in Southern California with R&D offices across the US and in Eastern Europe.

If you‘re planning to switch from one tech stack to another or you are just starting a new company, make sure to pay attention to this aspect.

Cost of development

Certain tech stacks are more expensive to build on because they are either rare (meaning there are very few developers who use them) or not optimized for speed (hence take longer to write classes/scripts in certain languages).

Another factor could be the cost of the supportive infrastructure such as servers and databases. For example, Oracle is extremely expensive, and very few companies would choose to have their solutions built on it these days.

Product security, scalability, speed, and other priorities

Your choice can be affected by your business and online product priorities too. For example, if you‘re building for the enterprise market, it would be preferable to go with Java tech stack. But if you‘re a startup and just starting out then the better option would be the MEAN stack (Node.js), Ruby on Rails, or PHP.

How we managed to build the product fast

The secret is in:

• Goals and project specifications;
• The right team;
• Project setup;
• Agile methodology in action.

It sounds like a lot, but professional software development is not a process where you can leave anything to chance. In addition, the online market has matured and requires a much more professional approach than it did 10 years ago.

Goals and Project Specs

Since Leadsmarket had a clear goal and a deadline, it was easy to plan. The lack of API documentation added moving parts to the project roadmap and the estimate. But it‘s always better to have a few blank spots in your project roadmap and the estimate rather than no plan at all.

Having properly designed project specifications is another important step. Even for ongoing projects, it‘s important to describe the overall project and the tasks for the first couple of agile sprints.

We describe the importance of project specification in more detail in this article  – How to Write Project Specification.

In the Leadsmarket case, they provided us with enough information to get started, including:

• The project description and clear goals;
• User stories;
• Wireframes;
• Tech stack.

Team

At the end of the day, software is built by people, so it‘s important to get the right team together. Here is how we recommend assembling the dev team for your projects:

• Firstly, you should have one person responsible for all communication with the dev team. It can be the Product Owner, Project Manager, or even your CTO or CEO (depending on your company‘s size and the project‘s importance). This person should be across all the project details and communicate with developers on a daily basis, even if it‘s just to say, “Hi, how is it going?”
• Secondly, you should have the following people from the dev team involved in the project:
  • An account manager.
    This person is responsible for the overall communication, the project setup, and guidance, both on the dev team side, and your (client) side. He/she organizes the processes. You may not need this person if the project is very small, but our data and experience show that it‘s almost always necessary.
  • A project manager.
    This person assigns the right developers and manages them on a daily basis. It‘s ideal if the project manager is located in the same office as the developers. He helps to organize the process together with the account manager. Overall, this person makes sure the developers work as efficiently as possible.
  • Developers and the designers (as needed).

This is obvious; these are the people who design and build your product.

It‘s extremely important to work only with an experienced dev team. Otherwise, your product will be a guinea pig for them. This applies to all parties – account manager, project manager, developers, and designers.

At DevTeam.Space, we assign mostly senior-level developers to our projects, whose core expertise is relevant to the client‘s field. Obviously, both the account manager and the project manager must be people with software development experience.

With Leadsmarket, we had the following team:

• Leadsmarket CTO as the product owner. Since it was a new business direction, he wanted to make sure we set the right foundation.
• An Account Manager from the DevTeamSpace internal team.
  • He assigned the right dev team, organized the whole process, and guided the client team along the way.
• A Project Manager from the dev team, assigned by our Account Manager.
  • He assigned the most relevant developers (ones that had been approved by the client team) and a designer. He was responsible for daily team management.
• Two developers
  • Senior front-end developer – 10 years experience.
  • Back-end developer – 6 years experience.
• A Designer

As mentioned earlier, it‘s important to have the project manager and developers working from the same office.

Project Set-Up

80% of project success depends on project management. At DevTeamSpace, we are focused on exactly that – nailing down the software development process. Focusing on that important aspect has allowed us to have a 100% project success rate over the last 12 months.

Since Leadsmarket had some blank spots in their project specification and API sides, we focused on the first two agile sprints (1 week for each) and started by outlining and estimating them in Pivotal Tracker.
As well as Pivotal Tracker, we always use the following set of tools:

• DevTeamSpace platform;
• Pivotal tracker;
• Github;
• Slack channels.

The DevTeam.Space platform is used for daily updates, roadblock tracking, and performance quality reports. It helps us to keep our finger on a pulse of the project and avoid burn-out on both the client and dev team sides.

There is nothing better to keep momentum than tracking performance on a daily and weekly basis, with obvious rewards.

Hire expert developers for your next project

62 Expert dev teams,
1,200 top developers

350+ Businesses trusted
us since 2016

Get started now

1. Daily bite-sized updates allow you to see what has been done. Our clients receive email notifications as well.
2. A sprint report is a more complex version of the report. Both the client team and the dev team are regularly evaluated across several important metrics (see the screenshot below). This data allows us to predict the project success rate based on current performance. These reports show where we need to adjust the performance so mistakes can be avoided, and the project can continue to run at a rapid pace. When your work is evaluated at such a precise level, you naturally want to perform better. That helps to avoid boredom or burn-out.

 

Performance report at the end of Sprint #2. Usually, clients don‘t perform as well as planned at the start of the project.
These data reports help to identify points for improvement very quickly.

Pivotal Tracker is one of the best agile product management tools on the market. We use it for forming the sprints. You can learn more about Pivotal Tracker here – https://www.pivotaltracker.com

Github is one of the most popular code repositories.
https://github.com

Slack is great for daily communication in text form and allows us to respond quickly, have a real conversation, as opposed to emails or Skype (where you don‘t have the ability to contact specific people).
https://slack.com

We set all the accounts for Leadsmarket and scheduled regular daily updates. After that, we were ready to start. It may seem like a lot of work, but the project setup can be done in less than one hour for small projects and in several days for major projects with an existing codebase.

Agile process in action

Design
We started with a first sprint kick-off call Monday morning PST. Since the project included the design work, we tasked one of our designers to come up with the initial project design concept and a clickable prototype.

One of the approved dashboard pages according to the client‘s requirements.

After this was completed and verified by the customer we allocated the development team with a Senior front-end (10 years‘ experience) and Back-end (6 years‘ experience) developer for the 2^nd sprint.

We had a very tech-savvy team on the client side. It included the CTO and a senior back-end developer who worked on the API part on the customer‘s side.

The client lead Front-end developer was available for consultations on the project structure, technology stack, and on building the code in accordance with the internal client team‘s standards.

Both teams worked in close collaboration because of the nature of the project – the API side was developed dynamically and needed swift reflection on our side. Sometimes it worked back and forth – the front-end needed some data (usually stats grouping) and the API needed to provide this data the same business day to avoid delays and meet the deadline.

Documenting everything
The project also required documenting all changes in the API and reporting all responses we needed. For this purpose, the client team created an apiary wiki, an internal bug tracker, and even an interactive data flowchart, which was a great help in the initial stage of development.

When starting the project, we had only a big picture of what was to be done and more details were provided as the project progressed. Agile methodology fit this model of development best, and since the client team was already familiar with Agile, the project started smoothly.

To learn more about how to make your organization Agile, read our guide on the topic.

Development
During the 2^nd sprint, we were mostly developing the client-side project structure on both ASP.Net and Angular2. To speed up the development, we purchased an Angular admin theme from Themeforest.

However, it turned out that it was not Angular in full and did not follow best code practices, so we had to spend a couple of days refactoring the theme and built the markup according to the prototype after that. (you can see that in the previous screenshot).

During the next sprints, we built the frontend for the system of creating HTML advertisement templates and gathered and processed statistics from the 3rd party websites where the ads were placed.

One of the most engaging tasks was building an advertisement template editor which allowed the creation of ad templates with dummy data and we then built actual ads on top of the previously created templates.

This saves Leadsmarket‘s employees and customers time by creating one template and reusing it when creating dozens of similar ads. Each view of a particular ad triggers a pingback to the API, increasing the view count as well as the earnings from each click on any ad, and the EPI for the website owners.

In this way, users are able to gather stats on the fly without any delays or caching.

Pivotal tracker at the end of Sprint 5. The client team handled the tasks in the icebox after the project was completed.

The project timeline
Overall, we had five weekly sprints with sprint start and wrap-up calls, as well as calls between the development teams to coordinate work when necessary.

The tasks were set in the pivotal tracker by DevTeam.Space‘s account manager after the sprint start call each week and were approved by the client CTO and lead developer.

On the sprint start calls, we reviewed the goals and user stories for the next week and formed them into tasks to be set in the pivotal tracker.

Hire expert developers for your next project

Trusted by

Get started Now

We discussed user paths, visuals, API interaction, and the internal structure of the code to comply with the client standards and make the code reusable and easy to transfer.

At the end of each sprint, we uploaded the code to the GitHub repository connected with the development server, which made the code accessible for Leadsmarket‘s internal QA. On the sprint wrap-up call, we collected feedback and formed bugs/chores for the next sprint in Pivotal Tracker.

We used Slack for everyday interaction and discussions and a few mid-sprint calls to clarify technology stack and code structure.

Results

As planned, at the end of Sprint 5 we handed the project over to the client‘s team. Working as a team extension, DevTeam.Space provided a significant boost to Leadsmarket‘s team performance, making it possible to finish the project on time.

Client‘s Review

Here is Leadsmarket‘s review after the project was completed:
DevTeam.Space developed the front end of our platform for managing PPC (pay-per-click) advertising. The team created an administration panel for our employees. Sooner or later our clients will manage their advertisements through the same admin panel, so the project will eventually be client-facing. The admin is built on ASP.NET Core+ Angular4. Our internal team handled the backend development, providing the API together with the documentation, so the final result was a collaborative effort.

What evidence can you share that demonstrates the impact of the engagement?
They added two developers and a project manager to our team, which allowed us to move way faster and complete the project on time.

How did DevTeam.Space perform from a project management standpoint?
They were exceptional. Our team members worked with them directly and the project management was of the highest standard.

What did you find most impressive about them?
They deliver what they promise.

What Is the Key to Success?

The key to success is the coordinated work of two teams.

Without the work of Leadsmarket‘s CTO and developers, we wouldn‘t have been able to finish their product on time. On the other hand, it wouldn‘t have been possible to build the product on time without a top-notch dev team and a data-driven, streamlined and transparent process from our side.

We‘ll continue to describe other important things in different case studies – it‘s always better to follow real-life examples.

How to Achieve More and Improve the Result

The simple answer is to go deeper than just code delivery and reports. I‘ll give you an example of how we approach every project at DevTeam.Space.

Every project is different. But every project is also the same – it‘s a process, and each project helps us to improve our process, identify more patterns, and to implement more automated solutions that enhance the dev team’s efficiency.

The product owner is a human being, not a company. And like every human being, the product owner is susceptible to psychological aspects. We have identified 6 different stages of the product owner‘s state of mind during development:

1. Feeling good
   The product owner feels good. The project has started, and everything seems to be going just fine. If colleagues ask him/her about the project, they might say something like, “It‘s all good”.
2. Not feeling so good
   The product manager hasn‘t really started to think about the project yet; he/she only feels uncomfortable about it. This may be caused by repeatedly delayed communication or long response times. At this point, there are no real negative thoughts in the product owner‘s mind.
3. Thinking negatively
   This stage occurs when the product owner starts thinking negatively.
4. Sharing negative thoughts with colleagues
   After several days of negative thoughts, the product owner starts sharing his thoughts with colleagues, maybe during lunchtime or over an after-work beer.
5. Sharing negative thoughts with the project manager on the dev team side.
   When it reaches the critical stage, the product owner contacts the project manager and asks to fix the situation.
6. Arguing with developers on a call
   If all the previous stages haven‘t been reversed, the product owner starts arguing directly with the developers and the project manager on a call. This may lead to the termination of the relationship.

Obviously, each stage can last just a few hours or several weeks. It all depends on the particular project and the person who is acting as the product owner.

At DevTeam.Space, we continuously improve our platform and data-driven processes so the client stays at stage #1 or is returned to stage #1 over and over again until the project is successfully completed. So far it has worked well, allowing us to have a 100% projects success rate over the last 12 months.

Why Others Fail to Succeed?

The majority of companies who come to work with us have their dark stories of product failures with in-house and remote developers. And the main reason they fail is that they underestimate the importance of the project set up and the project management process.

You can avoid some of the mistakes by preparing a complete project specification document.
Another factor is hiring developers who don‘t have the relevant expertise or don‘t work as a team.
There are other factors related to project failures, and we‘ll look at them in future case studies.

A Summary

I hope this case study, along with our expertise and lessons, were interesting and you have found it useful and applicable to your own company.

If you‘re looking for help launching your next online product or updating your set of online products, feel free to submit your project request, and we, at DevTeam.Space will help you achieve your goals better than anyone else because managing software development projects and bringing them to fruition is our focus.

Frequently Asked Questions