My agency has been developing an application that they're hoping will bring in a lot of revenue and they're going about it the wrong way. The agency usually only deals with wordpress and drupal type sites. Our typical client approaches us for 3-6 months of work on a custom theme and then follows up after that with maintenance work.

At the beginning of last year the agency took on a whole new type of client that wanted a web app built, both for desktop and a mobile version for phone. I was hired as a team lead because of my experience with React, React Native, and Node. This job scope is still pretty new to me. So for the past 18 months that web app has kind of been my teams life and we've been sequestered off from other projects.

At the end of last year the other teams started working on a new web app, however, as their main experience is in wordpress, they have attempted to build the entire thing in wordpress. My project is winding down and they've started noticing that the app we built acts much more like an actual app than a website and they want me to apply that to their project. The thing is, for the scale they want this applied to, the project should have never started in wordpress. They're trying to contort a CMS into something it's not. At the very least the only way react is going to play nice with their back end is to change the entire thing into a headless api.

This leaves me with telling them that the months of work they've put into the project were kind of a waste of time as they used the wrong tools from the outset. It's not that they didn't use react but that they didn't use any framework. Almost all of their front end manipulation is done by very hap hazard jQuery. The other issue is that they want to apply some very heavy data analysis to the back end and wordpress was never meant to do things like that so it's causing a massive slow down of the whole thing.

The person who would make the final decision on this has a very profit focused mind though (as a business owner should) and will really focus on 'time to market'. The idea of me saying the concept is great but the whole thing needs to be refurbished will immediately cause him second thoughts on anything I say after that. More so, as many of the original team members are unfamiliar with react, angular, or any other framework it puts them at an immediate loss. I can definitely understand the strength of building in what you know vs learning something new.

For example last week while discussing an npm package we'd used for the mobile version of our previous app the other team noticed we'd solved a big problem they were having and asked us to implement it for them. After looking at their code that's when I realized there was no way to use this npm module without setting up webpack or browserify in the project and they weren't about that at all. After 3 days we were able to write a vanilla js script that did what they needed but I have a feeling this uphill battle is what we'd be in for the entire time.

What is the best way to present all of this to them. I don't want to just say straight up "no we won't work on this as it is" but I also don't want my team taking ownership of the front end of the project only to take blame a few weeks or months from now when it can't perform as they want. Basically I feel like this is going to set us up to fail monumentally.

  • Welcome new user! I would urge you to click "Edit" and drastically shorten your question.
    – Fattie
    Commented Nov 26, 2018 at 3:31
  • It's sounds like a non-issue, Brian. It's totally commonplace, the norm, that opinions differ vastly on the basic paradigm of how to do some web site or app. It's a non-issue. It's like saying "I'm a programmer, today i wrote some code." Just speak up freely and openly at any moment "Oh I happen to think this should be done with XYZ." It's worth noting by the way that a great many architects totally dismiss React/ecosystem as a total waste of time and money. Opinions mean little or nothing in software, everyone has one.
    – Fattie
    Commented Nov 26, 2018 at 3:35
  • "The idea of me saying the concept is great but the whole thing needs to be refurbished will immediately cause him second thoughts on anything I say after that" - and how will he think of you, if you don't speak up & the whole thing ends in tears?
    – Mawg
    Commented Nov 26, 2018 at 10:10
  • Sometimes you get halfway up the mountain, look around, and see that you are climbing the wrong mountain
    – Mawg
    Commented Nov 27, 2018 at 8:29
  • @Fattie I'm not quite sure what you're trying to say. My question related to how they are building something and what they expect. My example, use of an NPM package in a vanilla js project exemplifies this. You can't do it. Yes we were able to work around it, but in 3 days time vs < 1 hours time. Didn't need to be React, but advocating all programming paradigms are equal is naive. My question was how to properly impress the severity of this to them. Simply saying "just say that" does nothing. If it was so simple I'd have done it. I was looking for other approaches.
    – Brian
    Commented Dec 9, 2018 at 15:17

4 Answers 4


Build a consensus amongst the technical team. Take what you've written here and bring it to the lead dev of the other team and see what they say. Preface it with "We can do it, but I have some reservations" and lay out your concerns.

If you get the other person to agree with you, you both bring it to the boss presenting a united front. For business decisions, you need to lay out time estimates and costs associated with either course - the one that brings the most financial benefits will usually be chosen by a rational actor.

On a business level it doesn't matter how pretty it is so long as it works sufficiently well that enough people are willing to pay for it to make a profit, and everything else is subordinate to that.

After that, you see what the boss says. If they agree, good. If they don't you do your best. At the end of the day it's not your company, all you need to care about is getting paid.

  • the thing I'd be wary of with this is the other lead is almost certainly going to disagree with changing anything, leaving us hobbling right from the get go. Is there a way to set accountability up so that we aren't taking blame for 'concerns' we warned them about but they opted not to listen to?
    – Brian
    Commented Nov 25, 2018 at 17:37
  • @Brian the way to avoid the accountability is to lay out all of your concerns and have them documented via email. If and when it falls apart you wave that at them and say "I told you so". Any face to face meetings where no records are taken, you write it up in an email and send it to all parties involved. Commented Nov 25, 2018 at 17:38
  • 1
    The "what's in it for me" can complement this approach. This can also be useful when we talk about refactoring to business as he may ask "we spent this amount of money to do this and now you are saying we have to redo everything ?" Commented Nov 26, 2018 at 8:11

You don't get involved with another teams project over which you have no control in terms of enforcing what is used and how.

If they request something, you refer them to decision makers who can then ask you if they want. If they do then this is the point at which you treat it as your teams project and let them know what would be required, timeframes etc,.

Ideally you wouldn't touch it unless it becomes your responsibility along with the authority to do it your way.


If the company culture allows it, I would have an open chat with the decision maker and, without slandering the other team, explain that you reviewed the requirements, and to apply your better performing solution the most efficient way is to recreate the other project from scratch. Nobody wants infighting or to make another team feel like crap, and the other team lead would probably get defensive, as he should, because of the original, suboptimal choice. So: talk to the decision maker, and let him make the decision. But make it clear that you don't want to cause a rift in the relationships with the other team. This is a massive exercise in politics, but you seem to have the right sensibility to make it.


Another possible outcome is that the manager decides the feature isn't important after all, or not important enough to rewrite what they have. You mention it will require great expense, but not how much it will help out.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .