1 of 31

Less hassle. Just business.

2 of 31

Architecture building problems in start-ups�on case of WE.VESTR

For those want to build a start up.

3 of 31

Goals

  1. Knowledge sharing�

The main goal of this deck is to share experience of building technology start-up with focus on architectural problems.

2. Start-up activity promotion�

Many of us have or had idea of building a start-up, but not so many people aware that start-ups have specific environment with not less features than Enterprise. Unfortunately main part of BY/Ukraine market is focused on outsourcing.

3. WE.VESTR can be your next journey!�

As we are entering scaling phase we have a huge need in bright minds. In WE.VESTR we are trying to build people-oriented culture & produce software solutions of high standards.

4 of 31

Disclaimer

  • Not intended to be truth in the last instance

This is not a scientific research, but experience sharing exercise.

Speech is based on personal experience & opinion in combination with other sources of information.

2. First version of this speech

This is only 1st iteration is this deck/speech. In future most likely it will be improved. If you noticed smth that must be fixed pls let me know

3. There is no guaranteed way to build a startup �Startup always involves risks. Please remember that

5 of 31

Who is in front of you

  • Started in start-up�My first job was small start-up studio in Minsk, it was focused on Taxi Friday app & start up for photographers & retouchers
  • Tried myself in outsourcing� I was working for LeverX (again for startup project) & then moved to EPAM. Made my first steps there as technical leader & architect
  • Developed multiple start-up like projects with 0$ as budget �First we created automated education administration solution with Rolling Scopes and enabled scaling educational processes from 300 students to 10.000+ annually. Went international.�And then participated in CSR platform delivery as Architect & Development lead.
  • WE.VESTR from 0 to Scale up phase

In SEP 2020 joined WE.VESTR as Head of Engineering. Now we have more then 100 B2B customers and onboarding dozens of them each week. Team size grew from 3 to 25+ in less than 2 years with more than 2.000.000 EUR investments acquired �

6 of 31

What problems we are solving?

7 of 31

8 of 31

WE.VESTR is all-inclusive equity management platform

  • Almost every start-up manages its equity/cap-table/finances in EXCEL (yeap we are in 2022)
  • Equity management is a deep dark forest
  • Financial inclusivity helps start-ups to grow 5% faster than those who are not using ESOPs
  • All the data in single source of truth!

9 of 31

 End Q4 2022:Smoke testing automated

Q3-Q4 2023:

Switch to independent team releases.

Timeline

November:Current sprint release

Currently:Manual regression�Previous Sprint release

 Q1-Q2 2022:�Core features e2e automation.

10 of 31

Let’s get back to September 2020

  • Only 3 of us (Founder&CEO, Product Lead/Designer & myself)
  • Around 150.000 € of investments
  • Idea validated on VERY high level prototypes
  • Shared office space
  • Fridge with beers
  • A lot of enthusiasm & ambitions!

11 of 31

There is no architect

  • Most founders are people with entrepreneurial/business background
  • It is very tricky question who should be a CTO in startup
  • One person – multiple hats
  • Continuous digital transformation is a key
  • “Enterprise architecture logged in the chat”

12 of 31

You need constantly validate your idea

  • The only true validation is $ payed for your product
  • Business demands PoC & MVP yesterday
  • You will fail. Fail a lot
  • Things always change

13 of 31

And you grow at the same time. Maybe as crazy

  • Processes that work perfectly for team of 5 would not work for team of 10. 25+ is different story and only here you can afford scalable processes
  • New comers wasn’t there when you started
  • Maybe someone already left?
  • Is it time to dedicate someone to architecture?

14 of 31

Everything starts with tools

  • Tools are being used by people
  • Know your hiring market
  • Choose tool – get architectural options for free
  • What if it is needed to change tools

15 of 31

SA is a reflexion of team setup

  • Everyone want to use tools they are good with
  • Architectural decisions will result in your place on hiring market as company
  • Haskell or Rust could be perfect tools for your problems, but will you be able to hire at this moment with current resources?
  • And again you will change both: team structure & tools you use

16 of 31

How our stack evolved

+

+

+

17 of 31

As well as our architecture & code evolved

+

18 of 31

Do you need micro-services?

  • Integration? What integration?
  • Did you had time to define architecture before going into microservices?
  • Are you sure this is a main priority for your problem solving?

19 of 31

In case you don’t need microservices (mostly)

  • Modules will do job for you
  • Focus on your problem and build architecture around it. You’ll be able to transform architecture if you have it.
  • Service-oriented architecture is also an option

20 of 31

Balance of scalability & fast results is vital

  • There are no ready solutions that will do 100% job for you, but there are patterns as well
  • Think big, start small, learn fast
  • Validation is a key
  • Split your solutions implementations into steps (trade-offs)

21 of 31

Built the product you want in the end (LEAN)

22 of 31

For start-up it is expensive, but can be for free

  • Clouds are expensive ,but every of them has start-up program which will allocate you some credits for 1-2 years
  • You can always try multiple programs :)
  • All-in/package products like (g-suite, microsoft office, WE.VESTR, twilio/sendgrid) can cover a lot of your needs. Yes they are not best sometimes from all options, but that will give you time to succeed.

23 of 31

Hire expertise & not man-hours

Front-end

Back-end

Data

Infrastucture

Test Automation

Quality assurance

TestOps

DevOps

IaC

Clouds

Another cloud

Blockchain

Cryptography

Enterprise Architecture

Solution Architecture

SDLC

CI/CD

Scrum

Kanban

Agile

Compliance

Networks

Fin-tech

Auth

Banking

24 of 31

Cap-table.How we reinvented OCF-like approach

  • OCF is open cap table coalition solution implemented by contributors from companies like: Carta, Morgan Stanley Shareworks & other competitors
  • Treat shares operations as banking transactions: credit/debit
  • More feature value for product -> more architecture efforts needed
  • But don’t over-engineer that will not help, proper trade-offs are important

25 of 31

Caching & computing issues

Transaction Type

Amount

Direction

shares-issued

1000

debit

correction

42

credit

shares-sold

500

credit

Saldo

1000+(-1* 42)+(-1*500)

  • With such setup it is resulting into situation when you execute a lot of read operations, but write happens not that often
  • Assumption was made that it will be easier to cache results on write & get them from cache on read
  • The only result was a need to refactor this part of application to get rid of caching in order to reduce complexity
  • P.S. we still don’t see any need in such cache

26 of 31

Previous projects results usage

Initial architecture was partially based on RSapp with DevOps features from other projects where I participated & replaced React with angular. That was one of the best re-usages. Saved us ton of time.

Other case of re-usage was a complete fail. One of our first developers re-used abstract angular http services from his previous project. We are refactoring them until now.

27 of 31

ESOP MVP case. Wrong assumption

  • We’ve made an assumption that most of users want linear vesting with monthly frequency
  • Validated it with couple of customers
  • Architect’s weren’t part of that process
  • Built MVP around that

Background

Results

  • Most customers immediately requested “golden path” feature extension (after MVP delivery)
  • We had to rebuilt it during 2 months and shift our roadmap
  • Rebuilt succeeded and now there are happy customers
  • But there is a long way ahead (ESOP is a rabbit hole)
  • Improved understanding of architect participation on company level

Takeaways

  • Validation is a key!
  • Fails will happen, use them for the good of your project
  • To achieve results you need good collaboration

28 of 31

Conclusion

    • Start-up is about balancing a lot of variables
    • There are specific issues for start-ups and patterns for their solution, but don’t forget to be creative
    • During the validation you will fail a lot, but use it for good. And in the end you’ll get your market fit

29 of 31

Special thanks to Rolling Scopes organisation �for all the things are being done there and together. Join us!

A

And to Gleb Shidkov. Lead front-end engineer @ WE.VESTR

for help & tips during this speech preparation

30 of 31

A

Where to find this deck & how to stay in touch

31 of 31

Thanks for attention�Your questions are more than welcome!

Let’s build some unicorns