0

There's an internal research and development application that has developed use cases based on our own vision for the product.

We are starting to get feedback from prospective clients from different industries to which this application could apply.

This application has working backend and frontend components. Both the backend and the frontend may need to be modified to meet the requirements of the client.

The frontend and backend communicate via an API that is generalized and not specific to any industry.

Since this application could apply to different industries the data in the database may change to include new data objects as well as current objects with new attributes.

Similarly, the frontend sections may change. Some sections not used or the workflow changed to meet the client's needs.

The way we see it, we could either have a Parent project (with backend & frontend components) that houses a lot of the core components with one or more child projects (backend & frontend) that inherit features and new changes from the parent, but have their functionality and visual style modified.

Otherwise, we just have a single backend with several frontend projects that that have different workflows and visualizations depending on the client.

This backend portion of the application has a Java-based backend with a database and other microservices. The frontend portion is an angularJS-based frontend.

Going forward what are the best strategies for determining how to organize and grow the project? And what are the common factors to consider?

Should each client get a personalized application or should we deliver a one-size-fits-all frontend with a modified backend?

Should we just focus on current client needs and not worry about any potential future clients until they come around?

1

Here's a summary of what you've said:

[frontend][backend]
[x][x] has working components
[x][x] needs tailoring for clients
[x][x] communicate via generalized API
[x][ ] sections may change

Option 1 ("The way we see it")

[x][x] parent project
[x][x] child project

Option 2 ("Otherwise")

[m][1] projects

Option 3 ("should each client get... ")

[m][m] personalized app

Option 4 ("should each client get... ")

[1][m] one-size-fits-all

You haven't inspired me with confidence that you can point to anything that isn't subject to change. You hinted that backend sections might not change but for all I know that's because the backend doesn't have sections.

Should we just focus on current client needs and not worry about any potential future clients until they come around?

Until you have a better idea what the future holds (and you might never) YES.

Write your code making as few assumptions about the future as you can.

| improve this answer | |

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.