Help for writing a proposal (RoR side-project)

Hello,

I am a new Web Developer working primarily with Ruby on Rails. I have been working with a Dev Team for over a year developing Web Apps, and I recently decided to start taking side-projects on my own in order to build my portfolio and get some experience.

I got in touch with a client that is willing to pay me for building a basic CRUD App.

I have a general idea of what my client wants, but he would like to have a proposal (with an estimate price) before moving forward.

I would like to be very professional and transparent throughout the whole process (starting with the proposal) and I was wondering if you have any advice or elements that I MUST include on the proposal.

So far, I found Thoughtbot's Playbook very helpful, and it mentions that it is better to not have a very detailed fixed bid (since the project might change or take longer) but to work under a budget and breaking the product into stages (Sprints).

My client understands this, but he would like to have at least an estimate.

Any advice? How do you calculate your hours? Do you include hosting (Heroku) prices as part of the proposal? Do you normally charge a monthly maintenance fee?

** I am planning on building a PWA using Ruby on Rails.

Reading articles from dev.to has become part of my routine, but this is the very first time I write something here. I appreciate your help! :)

Comments

[Casey Brooks]

There are a couple strategies my company uses for estimating project scope, which are all within a fairly standard Agile development methodology.

The first part of it is breaking the project down into "epics", which are the big, overarching features that the project needs. Things like "user accounts and registration", "customizable dashboards", shopping cart and checkout", etc. If you were to make a landing page to market this product, the features you'd include on that page would probably be "epics", as would the "big ideas" that your client wants. A project shouldn't have more than a couple epics. You really can't estimate the scope of an epic without breaking them down further.

Now you can take each epic and break it down into "user stories". This is still a very high-level overview of the project, not thinking about technical implementation or any of that yet. User stories should be described from the perspective of the end-user, with a common format of "As an X user, when I do Y, then Z." It helps to sit down with the client and discuss user stories together. For example, the "account and registration" epic needs stories like "create account", "verify email address", "login", "reset password". Again, still very high-level, but easier to discuss with the client, and easier to estimate the scope.

There are several ways to estimate scope. One example would be using "story points", and estimating a given number of points on a fibonacci scale. The value of a point might be hours, it might be days or half-days, or something else, but it is designed to be a loose estimate. For example, if estimating with points as days of work, you might not be able to say the number of days the story will take, but you should have a good idea of whether it is closer to a 3 (about half a week), 5 (up to a full week), 8 (at least one or two weeks), or 13 (two or more weeks). Another useful estimation technique is "T-shirt sizes", i.e. S, M, L, XL, which could roughly correspond to the same scopes as I showed with the fibonacci points, but be even more loose since you're not putting any numbers on the estimate.

Generally-speaking, if you have too many "L" or "XL" user-stories, you could probably find a way to break them up into smaller stories that are easier to estimate, and help keep the overall scope in check.

User stories are what you would agree on with the client, but when you start working on a specific story, it may be helpful to break it up further, into "tasks". A task would be a small, focused feature that needs to be implemented, and can be technical. With a "login" story, you know you will need an HTML form, Javascript to submit the form, an endpoint to handle the submission. You don't generally share tasks with your client, but creating and estimating tasks may be useful for you to estimate the time needed for a story.

[KathySRatcliff]

Writing an essay is not an esay task, And lots of students face lots of problem in writitng it. Well, I am thinking about making app, but I am not good in coding I found it really tough. But hopefully My friend suggest me about andromo.com/ where I can learn making an app, and for that you don't have to do coding much.

[JanRampling9]

Thank you for the provided information! Unfortunately, there aren't so many articles that offer such detailed tips, especially for people who don't have an idea how to write them. For me, it is much easier when I am guided step by step to do something. However, besides it, I am also using the best essay editing and revision site as I make many mistakes which sometimes I don't notice, so this is why I always send my essays to such services.