1

My boss is asking me to implement certain features in a web application (rails) that are relevant for only a couple users, sometimes just one user (the reason is this is targeted for businesses and a user has a high life-time value for him).

This is not simply "show different content to different users" though, the web has become pretty good at handling that. It's about actual functionality, like different form fields, ajax requests only for a single user etc..

While i can imagine ways to hack this up, all sorts of alarm bells go off: bloat and unmaintainability being the primary ones. Also, i can't find any web applications doing this very much (at least with the custom functionality growing as a function of the number of users).

I couldn't convince my boss yet that this is a bad idea, am i wrong here? I feel like a web app is not the right tool for this job. And if this is indeed a bad idea, what would the best way be for me to clearly explain him that?

Thanks!

4
  • Sounds like a very common problem actually. We have a web site that provides services for a variety of roles (like customer support, sales people, customers, product support..., an API for a web app). We have different functionality as much resource based (who can see what, customers can only see specific brands or assortments. Also single fields, eg employees can see inventory while customers can not) as based on functionality (sales people can edit certain fields customers can't, as whole blocks of functionality like statistics). It's not easy, but can be done and has been done. Apr 13, 2015 at 18:25
  • And this is where a lot of web will go. It's just super easy to access from everywhere. Also we have tools, often for free, that our ERP system does not have or that would be prohibitively expensive. Apr 13, 2015 at 18:27
  • JS that checks user state and redirects to another page on that particular role. Session check on the redirected to page that makes sure the user is supposed to ever get there. Just how I'ld do it. Apr 13, 2015 at 21:03
  • 1
    Whether this is a bad idea or not is entirely a matter of a cost/benefits analysis. Subtract the development cost required to support special pages for one user from the amount the one user will pay, and if you get a positive number, it makes sense to do. You just need to make sure all the real costs are accounted for. Apr 13, 2015 at 22:32

1 Answer 1

1

I couldn't convince my boss yet that this is a bad idea, am i wrong here? I feel like a web app is not the right tool for this job. And if this is indeed a bad idea, what would the best way be for me to clearly explain him that?

I am really not sure this is a bad idea. To me it sounds like a good idea because your customers will get what they want from you, not from someone with more agile processes.

It seems it's time for you to think about some plugin system in your application architecture.

This will allow you to make custom feature development isolated as a plugin without bloating the whole thing.

4
  • Plugins just feels right for this purpose. The downside is that once you have plugins it's tempting to implement everything new as a plugin
    – slebetman
    Apr 18, 2015 at 16:09
  • @slebetman I don't think the topic starter will have problems with this decision. Features, going to be used by all customers should go to the core. Various personal requests will be fulfulled by developing plugins, which could be then sold to other customers and be maintained separately by a separate team. Apr 18, 2015 at 16:11
  • Which is why I describe it as a temptation rather than an actual problem. The problem is not in the software but in the peopleware.
    – slebetman
    Apr 18, 2015 at 16:12
  • @slebetman Agreed ;) Apr 18, 2015 at 16:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.