EM Business Products Corp.
  • Services
  • Case studies
  • Blog
  • Connect with us
EM Business Products Corp.
  • Services
  • Case studies
  • Blog

03/27/2019

How I architected my own software product -- Devstimate

#product-development
How I architected my own software product -- Devstimate

Many of us software developers love to build things, and many are creating their own products to add additional revenue to their business, or just to make their own lives easier.

I created Devstimate as a product that will make my life a lot easier (and hopefully the lives of other freelancers out there), and hopefully in the future it can be a way to add a little extra revenue. We have to start somewhere, right? ?

I'll tell you how I came up with it.

Estimating... so tedious

I've been freelancing and running my own software development company for quite some time already - a little over 8 years. As any software developer will tell you, every project is different, each with its own unique items to consider.

We cannot really use a specific estimation "template" of some kind, that could cover all our cases. They just vary too much. There are some common things, but they apply sometimes differently, or with more or less complexity.

In a month I estimate projects for leads at least once or twice. The process for me goes like this:

  1. Lead provides information about their project, and provides wireframes, description, flowcharts, designs
  2. I use this information, go through all the documents and begin to form questions for the lead, to clarify details
  3. If things are clear, I begin the process of breaking down the project into logical chunks
  4. I break down each chunk into tasks, and estimate them
  5. Once I estimate all tasks within each chunk, I run these estimations through some form of formula that can give me a cost estimate
  6. I then calculate a lower/upper range for this estimate
  7. I add any necessary markup
  8. I then provide this quote to my client, with a breakdown of the work, and the total cost

I then relax because I won't have to do this tedious process again for another week or two.

Once I estimate, this estimation has been so customized, that I tend to discard it afterwards. It was of value to me for that client, but it won't apply for other clients easily.

I wanted to be smarter about how I used my time. There were some estimation apps and calculators out there, but I didn't feel I had the control I wanted. I wanted to be able to break projects down into tasks, and use some kind of base task as an estimation start, and modify if needed.

The idea to have the flexibility of re-using a task, applying default values when I wanted to, and overriding them when they didn't quite fit, was also something I really wanted.

I also wanted this to be a quick experience. I wanted to search through a list of tasks and find the one I want in just a couple of seconds. And just tap once or twice to add it. No copying or pasting from an excel sheet, and definitely not having to remember what I estimated the same task in the past.

I also didn't want to do math 😖

The app should do the math for me.

I also really wanted to estimate as I already did with Agile teams, which was by using relative estimation with story points. This yielded a more accurate estimation for me than just estimating by hours.

This is why I decided to try and build something that could help me and others estimate their projects. Enter Devstimate 😍

With Devstimate, I designed it to estimate in 3 ways. I can estimate by providing flat fees for each task, I can estimate by hours, and I can estimate using story points.

The first time I used it for an actual client, I could see the change right away. I was estimating a lot faster, and I felt less stressed. It was kinda fun almost, because it had everything I needed and I didn't have to think too much.

I hope I can give this feeling to other developers. There's a lot of work to do though. I just added the bare essentials into it for now.

How I architected the app

This brings me to more technical details, the architecture I wanted to talk about.

My architecture was based on some goals:

  1. Bring it to iOS and Android as soon as I can
  2. Don't invest too much time into it. Who knows if I will find it useful let alone anyone else
  3. Keep cost low, because, well, you have no budget

With this in mind, I went off on my adventure.

React Native

I decided to use React Native for this task. There was no need to do heavy native work for either platform, and I could share most if not all my logic through React Native.

I kept my idea simple to stick to my goals:

  1. No login at all
  2. Just a few screens that can be wired up quickly
  3. Minimal design, just focus on functionality
  4. Generate the totals in the simplest way possible
UI

I kept the UI simple, and with the help of React Native Elements and React Native Vector Icons I was able to get components in place that looked nice, without having to think much about design at this point.

For list swiping, I used React Native Swipeable. It was simple to implement, and worked just how I wanted it to.

I had the front-end tech decided on, and I really did not want to spend time building a back-end system. This idea is not tested, I felt it would waste time. I did need to save the estimation data somewhere though ?

Firebase

This looked like a perfect moment for Firebase, which is a serverless technology. I can save info directly to the firebase database, without a back-end.

Firebase also offers anonymous login. This means the user can log into my system anonymously, and their data can be organized by their unique anonymous ID. This was perfect. Saved me lots of time.

On the React Native side, I decided to use the React Native Firebase library. It's a very cool library which lets me use the native iOS and Android Firebase libraries in React Native. Couldn't have built it without it.

I wanted to shave some more time off by using other helper libraries in React Native. To help me with the Firebase integration into Redux, I used React Redux Firebase.

It was really helpful to have a lot of the Redux integration already handled for me, and the querying to Firebase is made a lot easier through this library.

For navigation, I used React Navigation, and my routes were simple, so there was no trouble at all here.

In total I spent maybe 2 months of part time work to get 90% of it done. The last 10% took very long due to my work schedule, and with the help of other developers we were able to finish the last lingering bugs.

What I learned so far

Since I built it, I've had a lot more experience in developing applications and using Firebase.

I think Firebase for this use case, was a perfect choice. The data is not that structured, and doesn't require heavy querying. The anonymous login sets me up perfectly for the future when I do add a proper auth system. Anonymous accounts can be merged into real accounts, so my users data won't disappear.

The built-in analytics also help me get basic analytics data into my dashboard, which is nice. I'm not too concerned with user counts right now, anyway.

I did learn that some of my initial ideas need tweaking. I think I can organize the tasks in an even easier set up, but adding the fuzzy search feature for tasks helped a lot in finding the task template you want.

One of the biggest things I overlooked, was the target platform for the app. It's nice to have an estimator handy in your phone, but I really would like to have it on my laptop too. I might build a desktop version in the future.

Marketing

Marketing is something I'm still thinking about. For now I'm going to try and blog about it more, invite other freelance developers to use the app, join forums, and try to get the word out.

I'm more concentrated on listening to users as they try it out, than I am anything else.

Conclusion

I'll be writing more about Devstimate for sure, and other things I work on. If you're interested in knowing a little more about Devstimate, check out my case study.

Also, don't forget to check it out for yourself, on iOS or Android.

If you find this sort of topic interesting please come by again. Also, feel free to reach out if there's any questions about the tech I used, or about anything about building products.

Like this article? Cool! You may like these:

CONNECT WITH US

Full Name

Email address

Message

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.