11–20 of 70 posts
One of my goto none coding interview questions is to have a candidate design a mobile analytics solution.
From the article, I've learned Google has a reference architecture: https://cloud.google.com/solutions/mobile/mobile-gaming-anal...
Just to flesh out the vendor comparison... Five weeks of, say, three engineers with $150k salaries ($200k fully loaded) is $60k. People say that the majority of software is after initial development. Let's say 20% is development [0]. That means this project costs $300k total and lives for 5 years before the team decides to rewrite it. That brings us to $60k / year. This is good savings! My general guidance to folks t…
The whole thing is a big ball of mud. If you commit to a vendor you risk vendor-lock in. If you commit to hand-roll you risk runaway deadlines, feature creep, and a slew of other threats. Once you pick one or the other and get it to a business functional level you lose all momentum and willpower to pivot to the best solution now that you have a "good enough" approach.
Just to flesh out the vendor comparison... Five weeks of, say, three engineers with $150k salaries ($200k fully loaded) is $60k. People say that the majority of software is after initial development. Let's say 20% is development [0]. That means this project costs $300k total and lives for 5 years before the team decides to rewrite it. That brings us to $60k / year. This is good savings! My general guidance to folks t…
The whole thing is a big ball of mud. If you commit to a vendor you risk vendor-lock in. If you commit to hand-roll you risk runaway deadlines, feature creep, and a slew of other threats. Once you pick one or the other and get it to a business functional level you lose all momentum and willpower to pivot to the best solution now that you have a "good enough" approach.
If things flip around again and you find a new library that solves your needs better than your homegrown lib, you can drop it in forking your lib and turning it into a wrapper on the external lib.
At least this is what I have learned implementing high flexibility cross-platform mobile video playback solutions in our app over the last 5 years, where the landscape of libraries (and our own tools) has kept changing.
240K - that's huge! I can't believe MixPanel gets that expensive - wow considering their plans are like: * FREE * 999 a year * Contact us That number 3 must be really spooky!
I had the opposite reaction. If you're in a big city in the US, $240K is the cost including overhead of one, maybe two engineers. If running this in-house takes up a total of a full-time engineering load (i.e., if the team maintaining this wants to add headcount to run this and maintain prior commitments), you haven't saved very much and you might be net negative. (The math may be different in different job markets,…
Our goals were to get high volume web data (pageviews, clicks, etc.) alongside application data already saved in our Firebase DB and synced to BigQuery.
We picked Keen because it has an open source web tracking lib https://github.com/keen/keen-tracking.js/ that easily plugs into our React/Redux stack.
They also have built-in streaming to BigQuery: https://keen.io/docs/integrations/google-bigquery/
Keen pricing is about 10% of mixpanel, so for our limited needs it has been working well.
Long term if our volumes really grew the original post looks like a good option, but figured we'd pass along this lower dev approach.
Unless you have restrictions about how your data moves and where it is stored, or need to have a trusted computing base with no externally developed software, or have very strict requirements that no available service implements (unlikely), you are better off just using an open source solution or paying for a service.
# Real cost
Even if you have to pay for a commercial service, in comparison, the TCO of developing a similar solution in-house is very large.
When you create a system in-house, you are paying for: design, implementation, testing, maintenance, deployment, infrastructure, security audits, training for users, documentation, and sometimes costs go beyond engineering, e.g: UX and graphic design and such.
After you are done spending all that money, you end up with a custom built service that is far from the actual main activity that supports your business.
# Quality
If you are to authorize a team to do something like this, audit their code constantly and impose a higher quality standard than you do for the rest of your applications. This is because this system will be a dependency for all your applications.
Even in large companies, it is unlikely that you have enough resources to have a large dedicated working on something like this. Because of this, requirements will need to be deprioritized or just neglected.
Because of this, you can lose all hope of selling this solution externally.
# Users
Then, since you are committing significant resources to your internal tool, it is likely that every single team will be forced to use it. That in itself is also a problem. What is better?
a) Learning how to use MixPanel, and put it in your resume (a skill that has market value and can be traded).
b) Learning how to use a proprietary system that is only used internally within a company. A skill that cannot be traded in the job market.
If I am a user, it is against my own self interest to push for an internally developed tool.