Architecture of psbFinances

Vladimir psbFinances, software ,

Every time you start a new application, you ask yourself: what should I use to build it. Should you stick to what you know or use something new. I’ve made a few decisions about the architecture of psbFinances. For the last 9 years I’ve been working with node.js, React and MySql. I’ve built platforms for 6 startups with this stack. That’s what I used for psbFinances. But there was a couple of decisions I’ve made “inside” this stack.

Note that React is becoming less obvious choice for me these days, but that’s another topic.

TypeScript (TS)

I am big fan of Anders Hejlsberg. I was working with C# since he introduced its first beta. Even before that I’ve used his Borland Delhi. When he announced TypeScript in 2012 I was very interested. He gave many reasons why TypeScript was developed. Great tooling support (like IntelliSence, code completion) was one of them. Since then I was checking the growth of it and was asking myself whether I should use it for my projects. I’ve asked the same question many teams that I’ve lead: “should we go with pure JavaScript or with TypeScript”. Interesting situation. JavaScript developers wanted to have static typing. At the same time more C# developers were asking for dynamics.

9 years ago most of the JavaScript IDE didn’t have a good support for it. But the situation has changed a lot since then. I use WebStorm. It has a very good support for pure JavaScript development, especially in combination with JSDoc. Visual Studio Code has a great support for it too. For me using JSDoc makes code less verbose and cleaner compare to the type annotations in TS.

As for the static code analysis. Incorrect types add only a minor number of bugs that I discover in my and my teams code. Most of the bugs are in the logical flow. Type validation is also address as part of unit tests.

TypeScript allows to use the latest features of JavaScript. Browsers and node.js may not support these features yet. But you probably use Babel and that solves this issue.

That’s why I’ve decided against TypeScript for psbFinance. I don’t see enough benefits to use another “super” language on top of JavaScript.

Some developers say that “you can’t build large-scale application without TypeScript”. That’s not true. Large scale application can be built using any language. I’ve seen quite enough of them built with different languages. It’s not about language. It’s all about the skills and discipline of developers.

GraphQL

That was another tool I decided not to use. I use REST API. A debate of REST API vs GraphQL reminds me a lot about the discussion between backend developers and DBAs. DBA didn’t trust developers to be “gentle” with their databases. They insisted that database should be accessed via stored procedures only. That make sense. To some extend. “With great power there must also come great responsibility”. That debate was won by developers who now can write direct SQL statements or use some ORM helpers. I was never in the DBAs’ camp, even though I’ve done a lot of DBA work. For developers that power of accessing database with pure SQL is great. But some of them didn’t accept the responsibility. Many times I’ve seen lazy SQL code that degraded performance and introduced security issues.

That’s why it looks the same for me with GraphQL If you built multiple applications with REST API then you know how to address some challenges.

I am not saying that GraphQL is bad or that it should not be used. Far from that. What I am saying is that based on my experience and skills it doesn’t give me any significant benefits while introducing some complexity. It also means that the potential pool of developers who can contribute to psbFinances becomes smaller – not everybody know it.

Conclusion

TypeScript and GraphQL are great tools. They can be very useful in the right hands. But for me they don’t have enough benefits to use in this project. Check the code and you can see that it’s ok to live without them.

psbFinances

Vladimir psbFinances

Do you manage you personal finances? Does mint.com ring a bell? Do you also have one or more small businesses and do your accounting yourself? QuickBooks anyone? Fraustrated managing same transactions in many places to see your financial health? You are not alone.

For the last few months I’ve been working on a project to address these challenges. Today I am open sourcing it. It’s a web application to manage personal and small business finances – psbFinances. But who needs another financial manager? Well, at least I do 🙂. Let me talk about what motivated me to create it.

I have been managing our family’s finances for a very long time (do you remember Microsoft Money?). Now we have two small businesses – my wife’s hairstyling and my softwrae consulting. I do our accounting myself. A few years ago we’ve had two LLC and one S-Corp. That year, I’ve used mint, QuickBooks Self-Employed and QuickBooks. Also I’ve had my own spreadsheet with a detailed budget, tax preparation toolkit, dashboards and cash flow monitoring. A lot of data and process duplication. A lot of frustration. I am ok to pay for the services that I use, but I cannot stand a free version full of ads or have a very pushy marketing.

I’ve tried many other applications during the last 6 year. Every time I’ve heard about a new financial manager, I tried it. Unfortunately neither of them had what I need nor saved me time managing finances. That’s when I finally decided to create my own. That’s how psbFinances came up to life.

The version that is available today is a beta. I don’t consider it ready for the “prime time”, but I’ve been using it to manage all our finances for the last 5 months. I have much better picture of our finances and spend less time managing them. Also it is easy to add a feature that I need to help me. I use mint to download our financial data from many banks, but manage everything in psbFinances. Even my own spreadsheet is now 90% obsolete.

Who is it for

psbFinances is not intended to be a tool for everyone. At least as of today. The most benefits from it will be for people who:

  • manages their personal finances
  • have one or more small businesses, and
  • do accounting themselves, and
  • would like to have all financial data in one place

Here are example of a few real life situation that psbFinances can help:

  • have you ever bought something for your personal and business needs in a single transaction? Easy to handle in psbFinances. But: “aren’t you supposed to make 3 separate purchases in this case?”. No, as long as you allocate amounts to personal and businesses
  • have you ever checked whether you will have enough cash to pay all your bills by the end of this or next months? Or play “what-if” scenario (e.g.: can I afford to buy something or put some money to a saving?)
  • do you have a detailed budget for each category and each month, rather than one number for all months?
  • do you want to let your partner to change the data, but can also see who did it and when?
  • have your data always ready for your Form 1040 Schedule C?

This is a small number of cases that I’ve tried to address so far. Take a look at it and maybe it will help you too.

Building successful MVP with offshore team. Project Manager.

Vladimir Startups , ,

This is part 4 of the Building successful MVP with offshore team.

Now you have a specification of your application and developers. It’s time to put on the next hat – project manager. That’s the key part to your success – you have to manage the development process.

A quick note before we move on. You should own the code. Never let developer show you the pieces of the product without giving you the code. Create an account on github and make sure that developers work with a repository there. You SHOULD OWN your code.

Manage and prioritize the work. Don’t create a list of features and let the developers decide what to work on. Tell them what should be done in what order. Work on the unique features of your application first. Do not start with Sign In, Sign Up and so on – features that are common for most applications. Build the core of your application first. This way you can address the most challenging and unknown parts earlier in the process.

Tell developers to show you how UI will like ASAP. There is no need to build the whole backend with API and database to show the actual UI. Developers can always use fake data before building the backend.

Use kanban board to prioritize the work. Here is a good example with Trello. I usually have the following boards:

  • inbox (all new items come here before being prioritized)
  • V1 or V2 or MVP or whatever version you plan to release (try to schedule only the version that you are working right now)
  • Next Up – the next items that developers should work on (no more than 2-3 items)
  • In Progress – this is what developer is working on right now (there should be no more than 2 items here, e.g. a feature and some urgent bug to fix)
  • Testing – items are under QA’s testing
  • Done – items that are done & tested
  • Later – everything that you plan to work on after the current release

Most of the work items (bug, feature) move this way:
Later -> V1 -> Next Up -> In Progress -> Testing -> Done

Don’t overcomplicate it and create too many boards for any possible scenario and development steps. If in doubt – put items in the Later board.

Lear how to triage bugs. Not all bugs should be fixed, even critical ones. Consider the probability of the bug. It’s like insurance – yes if some bad thing happens, it can be costly, but the probability of it is so low and insurance is so high that it doesn’t make sense to have it.

Ask a developer to commit the code daily, especially at the beginning. This will give you a sense of the progress. Review the new code daily. No, you don’t have to learn to program nor to understand the code. But if one commit has a few lines added (sometimes these can be blank lines) and then removed in the next commit, it’s not a good sign. Look, it’s like writing a book – if an author writes only 100 words per day, it’s not good. GitHub will let you compare the changes. You can also track the progress with GitHub activity monitoring tools.

Be proactive. Get everything ready for the next item the developer will work on ahead of the time. Prepare UI design, UX flow, business and data validation rules, and so on.

All this work should not take you too much time. Depending on the number of developers it can be no more than 2 hours a day. Yes, it looks like a lot of work, but this is the road to a happy and frustration free launching.

Building successful MVP with offshore team. How to find a developer.

Vladimir Startups , ,

This is part 4 of the Building successful MVP with offshore team.

 

This is part 4 of the Building successful MVP with offshore team.

Where to go?

One man said:

If you need a code – hire developers from India, if you need a solution – from Eastern Europe.

India and Eastern Europe supply most of the offshore developers. There are very common advantages and challenges working with developers from these regions.

Indian developers work best when you need very common applications like CMS, e-commerce, social network and so on. They can deliver such application very fast and with an acceptable quality. Their English is good, but time difference can be a challenge. Also, they tend to work with older technology stacks. Nothing wrong with that, of course. But if later you consider growing the engineering team in-house, this may present some challenges.

Eastern European developers work better on a project that is unique and requires more research, like IoT or ML applications. The time overlap with Eastern Europe is better, but English may be more challenging. Focus is another challenge. Quite often these developers are more interested in writing code rather than delivering a working product.

There are also good developers in Western Europe, Latin America, China and the US, but I have less experience with them.

Selection criteria

Here are the criteria that I use to select the candidates:

  • hourly rate that fit my budget; check the actual rate that freelancers have charged on recently completed jobs because quite often it’s lower that posted rate
  • region (see above)
  • agency – in most cases I try to go with agency rather than a single developer; agency can provide more people if needed or substitute a person if developer is sick or on vacation; but they can also quietly “downgrade” you – give you a senior developer at first, but then replace him with a junior one without telling you. Yes, unfortunately, this happens.
  • total hours worked, especially recent hours
  • success rate and feedback.

Select 5 – 10 candidates and invite them to apply for the job.

Now, about the fixed scope. I would not recommend doing it. It almost never works. Because you have to prepare a detailed specification of the whole application upfront. And whatever price you get will be wrong, because at that moment for most of the freelancers its important to get the job and they will underestimate the effort. It’s better to describe what you need in general, get a rough estimation and then multiply it by 2. The actual time and cost depend on how well you will manage the project. I’ll talk about this later.

When you select candidates, ask for their work – anything that they can show you, whether it’s a completed application or code. Check it, but you cannot be sure that this is really the work of that developer.

Now you have your candidate and ready to go ahead full speed. Stop, don’t do it. Test the developer first. Select something small that should be developed, like Sign Up feature, or Forgot Password or list of the blog posts to show. The developer should be able to get it done in 2 – 5 days. Ask the developer to give you an estimated completion time and work with him. When the feature is done check the following:

  • whether the actual completion time is close to the estimate
  • was it easy for you to work with the developer
  • how many bugs you found in the completed work

If you don’t have any red flags, then hire this person for the rest of the project. Otherwise, pay for the completed work and try the same process with another candidate until you find the right person. Yes, you can loose some money short term but will lose much more if you will continue with the wrong developer.

Building successful MVP with offshore team. Part 3.

Vladimir Startups , , ,

This is part 3 of the Building successful MVP with offshore team.

Remember – the more details you let the developer interpret freely and assume, the more likely you are going to fail. Think about it this way – if you decide to build your own house, will you tell the builder that you would like to have a gorgeous open floor plan house with 4 bedrooms? I guess not. You will go through each detail of your dream house before any construction starts.

Product manager

Product manager converts your vision of the application into the exact specification of what user will experience. This includes the exact steps of how a user navigates through your application, mockups of each screen, any data validations and so on. The key word is “exact”.

Let me give you an example. It’s not enough to tell a developer that you need a Log In functionality. You should provide the exact details about it:

  • Should it accept email and/or username
  • Any restrictions about username and password
  • Error message if Log In fails or any field is missing
  • Should user be able to stay logged in (Remember Me option)
  • Should log in ever expire
  • How you are going to handle “Forgot my password”
  • and so on and on …

“But this is too much work to describe all these details. Shouldn’t developer already know all these?”. No, but he will assume, and that’s not what you want. Believe me, you will do this work anyway. It’s just a question whether you will do it upfront or after the coding is done, the result is not what you need and it should be rewritten. Doing this work upfront saves you time and money. It also gives your QA the exact testing plan.

Now the question is how can you nail all these details upfront? It’s not that difficult, just don’t try to invent a bicycle. Find any popular application that has a similar functionality and check how it works. For our example with Log In, you can try Facebook, Gmail, Instagram or Quickbook. Try all possible scenarios, write them down, apply for your own case and pass them to developer and QA. You should discuss this specification before any development is started. Make sure that it’s very clear for developer and QA that they should not assume, but ask.

Be proactive and you will succeed.

Building successful MVP with offshore team. Part 2.

Vladimir Startups, Uncategorized , , ,

This is part 2 of the Building successful MVP with offshore team.

What is MVP?

Let me define what I mean by MVP before going into recommendations. MVP is a product with the least set of features that founders can use to test their business model. You have to consider whether it’s a throw-away or a foundation for your real product. Most founders start MVP with a throw-away approach in mind. They would like to build something quick & dirty and test with a few clients. They plan to build a solid product if MVP has some traction.

It doesn’t work this way in most cases. Founders continue building on top of the throw-away MVP as soon as they get some traction. And soon they have a code that’s difficult to maintain and grow. Their application doesn’t scale and performance is bad. And sooner or later founders face a taught decision – invest into rebuilding the product.

It should not be this way. It’s possible to build a prototype without any investment at all (I am talking about cash, not time). You can do the UI in Sketch and test the UX in InVision. These are very valuable tools that any founder should consider mastering anyway. BTW, I discourage a common theme on startup forums- learn how to code. Programming is not easy. It will take a lot of time to learn it to the level where you can produce something beyond “Hello, world” application.

Originally published at syerik.net.

It’s possible to build MVP on a solid foundation that will be a “keeper”. And it does not need more time or money to build than a throw-away product. I’ll be describing how this kind of MVP can be built.

Developer is not enough

 

Steve told me: “If only I could find a good developer …“. If you also think that the “right developer” is the way to success, sorry, but you are wrong. If you think that you can pass your vision to a developer and get it back as an application that is close enough to it – forget about it. Save your time and money.

To build a good MVP you need:

  • Product Manager – translates your vision into actual product behavior
  • Project Manager – triages the work and makes sure that it’s done on time
  • UX/UI Designer – defines the experience that users get from your application
  • Architect – makes sure that the “foundation” of your application is good and you will not have to throw it away later (optional, but …)
  • Developer – writes code
  • QA – finds the bugs and verifies the fixes

If you find a developer who can wear all these hats – great, but it’s not going to be cheap. Now, you can hire people to do PM, PrM, UX/UI, QA. Or you can do it yourself. In any case – there ain’t no such thing as a free lunch – you will pay for this work with your time or your money.

I will share how you can do all these work yourself in the next posts (it’s going to be more practical).

Building successful MVP with offshore team

Vladimir Startups , , ,

My friend Steve (not a real name) called me recently. He would like to launch a business. He has an idea, business plan and some money to build an MVP. His question: How to? Steve cannot afford SF BA developers. His option is to go offshore. But he heard a lot of scary stories about working with offshore developers.

I’ve heard them too. A lot of them. People had a very bad experience. They will never deal with developers who are not with them in the office anymore. It hurts, I know. I would feel hurt and furious if my personal money were on the line.

But I’ve built successful high-quality applications with offshore teams. And the cost was a fraction of what it would cost to build in the Silicon Valley. I’m not the only one.

I gave Steve some recommendations. I will share them here in the next few posts. Steve can build his MVP offshore. He can do it fast, on budget and without a stress. These recommendations may be useful for you too.

Giving birth to a software

Vladimir software

There are a few exciting moments for a software developer when he builds a software (and love doing it). First “clear” run, 1M customers using it without a problem, … For me the most exciting moment is the “birth”. At first there is nothing, nothing material – just some thoughts in the people’s heads. And then you create a folder, name it, add some files and run it. And it runs. It does nothing really, but it runs! There was nothing, and now there is something. This “something” is small, useless and ugly, but you see the future beauty of it. You see people who will use it, love it (or dislike). It will solve their problems and make their life easier.

But it’s still just yours at this moment. And then you commit. And boom, it’s part of the world, not just yours anymore. Even if it’s only your partner or code repository who knows about it. It’s out “there”.

And although I do it every day for some “exploration” projects, it’s different. That doesn’t bring that excitement. But starting an application that will “live” is like planting a tree or breaking ground for a new home. I may not see the tree grow or build the most of the home, but it’s all about starting it. Yes, I love to see a working product in the hands of the people. It feels good. But starting it …

I see quite often auto-generated comment in the code “Created by …“. I never like it. But when you commit the code, you have to give your name. And I know that there are a few products around that have my name at the root. And it brings a happy smile to my face 🙂.

A few day ago a new tree was planted …

Stop using Slack

Vladimir Process , , ,

stop-sign-clipart.png

Confession – this is a flashy title to attract an attention. Slack is a great tool and you should use it. But, please, STOP abusing it.

Let me explain my point of view. It’s a great tool to have a conversation with your team members. But it should not be used to preserve the knowledge. What knowledge? Anything that related to your work like discussions about product features, roadmaps, decision points and so on that you may need to reference back in the future.

Let’s say you have to discuss a specific feature of your product. I assume that you already have it tracked in one of the applications like Trello or Asana. It’s so tempting to just jump into one of the Slack rooms and start the discussion there. But unless you have a room for each features, bug, task don’t do it. And, no, I don’t advocate to have a room for each working item you have to discuss. Instead of going to Slack, find this item in the tracking system that you use and discuss it there. Your discussion is the knowledge that you would like to preserve. It can be useful for you in a couple of months or for your teammates when they will need it later. One item – one place to store everything important about it. It makes much easier and faster to find information when you need it.

Have you ever came back from vacation to find your Slack room full of unread messages? No? Well, I guess you don’t use Slack then :). How can you get up to speed with any decisions that were made about a particular task? Search? Read all the messages in a particular room? But it has discussions about 10 other items, all “shuffled” and polluted with totally unrelated chatty messages. But if that discussion is kept with an item itself in the tracking system, then you will get what you need right away.

Are you a manager? Then you have to track all work items of your team. But you don’t have to track ALL of them right away. Some need your attention right away, but some – can wait. You know that there is a discussion going on, but you don’t care about it right now. You will deal with it later. But when the time will come, you want to get up to speed fast.

So, do use Slack. But keep your knowledge where it belongs – with your work items. A small effort to put the information where it really belongs will go a long way when you will need it.

Urgent vs delayed

Another disadvantage of Slack comparing to email + IM is no explicit sense of urgency. In most cases, when we receive email, we know that we can reply later (unless it’s stamped as urgent). But when somebody pings you via IM, it means that there is a need for an immediate reply. Well, this is how it is in most cases. And this is not very clear with Slack. Unless you read the message, you don’t know whether a response is expected right away or it can wait.

This is not a big deal, because it can be easily fixed with some tag or “stamp” of the post. Just agree with your team what it will be.

And remember, a tool only as good as the user.

Happy collaboration!

Goodbye postach.io

Vladimir Misc

Some time ago I’ve moved this blog from self-hosted WordPress to Postach.io. The folks at Postach.io had a very nice idea – write your posts in Evernote and just publish them from it. And I love Evernote. I use it a lot. So, it was a very easy choice for me.

But later Postach.io went from a free and subscription model to subscription only. And the price ($10/month) was too much for me. I was not alone. I’m not sure what the future of  Postach.io will be, but I think that price should reflect the value.

So, this weekend I’ve moved back to WordPress. Even after a few years away it feels homy. It’s good to be back.