I'm working on a hobby project for a game - it's in an alpha state right now and I have users using it.

For the past 9 months I have been the sole developer, but now I found someone who was willing to do the web development side. In a few weeks time they have made great strides in rewriting the website so that it looks and feels so much better.

Over the past few days we've been talking on Discord about how to merge our work, and this is where things have gotten frustrating...

He's suggesting large swaths of changes on functionality that already works. 'Stop using Stored Procedures, do it the Laravel way and build the query in your api', 'Stop using sockets, switch to web sockets and send http requests', 'scrap your mvc project, and rewite everything as a rest-api', 'rewrite your database in postgresql or mariadb', 'if it was any other developer, they would tell you to scrap .net and use Go and Vue'.

I've spent more time arguing and defending the code I wrote vs actually cooperating and getting the project further.

I've tried my best to explain why I am against these sorts of things. I'm not familiar with even half the technology frameworks/languages he was suggesting we switch over to, and I don't feel like rewriting my entire codebase in some new framework that I have zero experience in.

I'm starting to think that the two of us are too different (he's a linux, cutting edge, hate MS kind of guy; My main stack is .NET, and I don't follow the recent web trends as closely')

I wonder if it's best to just end the partnership and go our separate ways? Or continue to try reasoning with him?

  • 10
    Did you pay the other developer to do the front end for you? Was there an implication or explicit contractual agreement as to who owned the code that he developed? For that matter, do you have a contract between you at all?
    – Jane S
    Commented Feb 26, 2018 at 1:57
  • 1
    What happens if you refuse to do those changes that he asks for?
    – Masked Man
    Commented Feb 26, 2018 at 2:40
  • 3
    @Stralos He is right in some aspects - I was totally ok with him rewriting the website using Vue and Node.js, hell I am ok with writing a rest api to give him the methods and data he needs. But I am not ok with spending another 6 months rewriting everything in a new stack that I would have to also learn (and probably fail the first time around). He may think going with newer stack would be more scale-able, but that is highly dependent on the individual skilled in the stack. Changing stacks isn't going to automatically make things more scale-able, you need the skill to follow through.
    – Igneous01
    Commented Feb 26, 2018 at 15:56
  • 7
    "he's a linux, cutting edge, hate MS kind of guy; My main stack is .NET" it was a very bad idea to ever work together.
    – Fattie
    Commented Feb 26, 2018 at 18:17
  • 3
    @Cris It sounds like you're not a very good developer. You have absolutely no idea about what his project does or how it works, but you're instantly sure that his database, framework, language and method of storing data are instantly wrong? There's tradeoffs on each of those things that you can't even begin to evaluate in the brief post here. I suggest you actually learn to gather requirements and evaluate different paths before making posts like this. Commented Sep 3, 2018 at 19:08

6 Answers 6


Define an interface and clearly divide responsibility

Like most web projects, yours has a clearly separated front- and backend (probably more so after the frontend rewrite), with a specific interface inbetween. Explain that you're willing to give him the interface he's asking for (REST API), but that the backend code - any part of it - is off limits. Hammer out the functionality of that interface together, but treat the code that connects to it as a black box - on both sides.

In any project that involves more than one developer, it is good practice to code against well defined interfaces. This way you isolate your code against implementation level changes and allow for parts of the project to be modified or replaced without affecting the rest. It also allows developers to work together on a project without having to know, understand or agree on all of the code and technologies involved.

Insist on writing down a specification (can be simple) for this interface, and insist that changes in this document have to go through both of you.

This approach serves three purposes:

  1. It should help you work together more effectively by clearly stating responsibilities and expectations. Whenever he brings up an implementation detail on the backend, point out that it's not in the scope of your discussion.
  2. You can use it as a basis for discussing shared concerns like gameplay.
  3. If you end up going separate ways (and he takes his code with him) or a few years down the line you notice your tech stack really doesn't scale well enough, you're left with separate, functional codebases and can replace parts as needed. Which you can worry about when it actually becomes a concern instead of wasting time arguing over it now.

If he's willing to agree to these terms, I believe there's a good chance you can be very productive together. If he still insists of a complete rewrite, your best course of action is probably to end the cooperation there.

  • 3
    I'm accepting this as the answer - that is not to say the other answers did not help - they certainly did help me form my response to him. I gave him an ultimatum with some freedom and he accepted. Now we are on track and the responsibilities divided.
    – Igneous01
    Commented Feb 27, 2018 at 14:54

From the sounds of things, your fellow developer is going to be unflinching in his opinion of your approach. The more work you both do on this game, the more argumentative he will get. It also reads as if he has not provided any convincing reasons for making the large-scale changes he is demanding.

Assuming you have never given him official joint-ownership of the game, politely tell him that your practices are too different to work effectively and that you two should part ways amicably. The loss to you is that he will probably take the work he has done with him, but it will pay off in the long run to work alongside someone who is more appreciative of the current setup.

  • But what if the other developer was right?
    – Sandra K
    Commented Feb 27, 2018 at 14:30

Couple of things. First of all: this is a hobby project. Your hobby project. The other developer was brought on to help you out with the website. Maybe I'm missing some information, but why does he think he has a say in what you're doing with your project? You are most likely in a learning process while enjoying something you like to do in your spare time (assuming you are going to school/working). You have already spent 9 months on the project, are you willing to throw that all in the bin by porting it to other languages opposed to developing new features or improving stuff? His suggestions hint at scalability. I do not think that applies to a hobby project such as this unless you really plan on achieving a large user base.

To come back to your question, seeing he wants to change a lot of made decisions it's best (in my opinion) to let him go and move on solo. He's helped you out with the website as per your request (and according to your story he had no other role) and you are happy with the work he delivered. It's fine to leave it at that.

Also, opposed to what BoboDarph suggested in his answer, I would not allow him to fork your work. Again, this is my opinion, but this project is quite proprietary and has cost you a lot of hours (and not to mention possible headaches). Are you willing to let others run free with all that you've worked hard for to achieve (read: game in current state)?

  • I anticipate a small user base (less than 1000). It's a game/mod for a very niche game (think MS Flight Simulator levels of niche). I've explained this to him as well - it makes no sense to over-engineer an open source mod that is not targeting millions of users (and even if it did, paying for the infrastructure to support such a userbase out of pocket would turn this into a job/career rather than a hobby)
    – Igneous01
    Commented Feb 26, 2018 at 15:49
  • "I would not allow him to fork your work." - The project is open source the author can't prevent this from happening.
    – Donald
    Commented Feb 26, 2018 at 16:16
  • "Over the past few days we've been talking on Discord about how to merge our work, and this is where things have gotten frustrating..." There currently is no work to use, the other developer still has it all.
    – WendyG
    Commented Feb 26, 2018 at 16:51

Thank him for his time and his contributions, then politely but firmly end the partnership.

You should of course keep this amicable, and you can give reasons if you wish (such as your approaches with the tech stacks you want to use are too different), but don't compromise. If it's open source, then you could encourage him to fork it and make the changes that he wants until his own guise.

In the future, my advise is to vet people thoroughly before letting them on board, and don't be afraid to turn them away.

I have a reasonable amount of experience in a similar light - I've been the lead developer for the best part of a decade on a niche, but at least moderately successful open source project. We regularly get offers of development help now - perhaps a couple a month. On average, we've probably had about one helpful person a year - the rest have been turned away in various forms. The usual approach we take when we get someone who seems interested is this:

  • We have a copy / paste paragraph about how they can submit a pull request, but we're not obliged to take it, they shouldn't assume that we will, if it's something that doesn't have a ticket filed against it then it's unlikely to be accepted at all, code is subject to these quality rules, etc. Around half we never hear anything back from after this.

  • Whenever someone suggests a major change (framework change, major code restructure, etc.) we have another copy / paste paragraph thanking them for their suggestion, and saying that we'll consider it over the course of the next few months, but we won't accept PR's for such changes. We had at least one guy try once anyway.

  • Almost no-one gets commit access. All other contributors work through PR's that are code reviewed, and one of the three regular developers has the final say (usually if unsure we'll decide together.) The decision is final.

Have we offended anyone this way, or got rid of useful contributors / contributions? Almost certainly. But this is a hobby project, and so I choose not to bog myself down with self-created debates and bureaucracy. If you enjoy engaging with people in this way and having these long debates about whether their idea / approach is better, and whether it's worth rewriting the entire system from scratch then by all means, go for it. But if not, then don't let yourself get sucked into it either.

  • For others users, please see first that the accepted answer worked for OP. Leaving should be only an option when you really tryed at least what the accepted answer said.
    – Walfrat
    Commented Sep 4, 2018 at 11:20

If push comes to shove (and from the looks of it, it has), tell your helper she can always fork your project and then she's free to use anything she wants on the backend. Otherwise it's your way or the highway. People seem to think developing opensource software is a democracy. It's not. Someone will always have to say "use this, not that" or "we do it this way not another way". And for the time being, that someone is you.

  • Good point, but the question never mentions open source though.
    – kapex
    Commented Feb 27, 2018 at 9:09

If you focus and your "friend" or "teammate" is to create a bigger, more polite hobby game (focus on hobby here), let's focus on better features, not tecnologies: what is best for your players? Fixing bugs/add new features or change tecnologies?

Be pragmatic: change tecnologies like you notice involve a lot of learning and time, so maybe is not best commitment for your free time.

Side note: if someone is trying to help you, listen first. From your questions seems to be after listeing phase and already on "defense" side of communications, means that you already decided to not switch tecnologies or change anything. What are reasons to change stack ?

You must log in to answer this question.

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