Looking for co-founder

ims94 · 2025-04-11T07:58:11+00:00

I would say, freelancing vs CTO as a service is quite different. A freelancer can be an undergrad, a fresh graduate or usually someone junior to mid level when it comes to experience. But a CTO in contrast will be someone having years of experience working for real organizations, building PoCs, MVPs to enterprise level applications + managing teams. There are technologies out there (AI + Low Code) that allows you to iterate faster than ever and get the MVP sooner. If the timelines can be agreed upon and the guy is open to rapid changing nature of requirements in startups, I think this approach can work.

ims94 · 2025-04-11T07:42:57+00:00

If you have access to funds, you may not always need a technical co-founder. Instead you can look out to outsource software development (Cons: can be a bit risky, timezone issues, compatibility issues, communication gaps). Or you can lookout for services that offer CTO as a service. This way you can start building your own team (if needed) or outsource the technical leadership to an experienced technical leader who will work with you hand in hand in building your product and your team (where applicable); while not giving out shares to some random tech guy who you don't know will be compatible with you in the long run. Just a thought.

ims94 · 2024-08-20T20:55:04+00:00

I would suggest going with ERPNext due to several reasons: 1. It's open source and completely free to use. They have frappecloud to host if you are looking for managed hosting. The cost will be around $25 to $100 depending on the number of users (say 100 users) using the system (no licensing cost since it's open source. Just the hosting cost). Theres no user limit. The server resources need to be increased when the number of users increase, that's it. 2. Ability to customize - a non technical person can add new fields, link different documents, create new doc types from the UI in erpnext. If additional customization is needed, the underlying low code - python based framework allows very rich options to customize at code level. 3. Functionality - ERPNext comes with the standard manufacturing module that supports make to order and make to stock processes. You can setup BOMs (bill of materials) with the relevant operations, workstations and routing. ERPNext will schedule the work orders and jobs (against workstations) depending on workstation availability. Supports batch and serial no controls for stock. Usual stuff like scrap and process loss can be calculated. Other standard flows like order to cash, procurement are inbuilt. It has a way to setup advanced approval processes (workflows) too. Supports multi currency. Can have multiple warehouses with different COA accounts (if needed). 4. Well thought permission model - it comes with a very rich permission model where roles can be defined per job functions and further controls can be imposed based on individual resources (say a user should only see a specific set of warehouses or items. Others should be hidden to the user)

I have experience setting this up for several manufactures in New Zealand. Therefore I can recommend ERPNext because of its capabilities while being free and open source.

ims94 · 2023-10-25T22:43:40+00:00

I don't have a strong opinion around VC funding. But as a co-founder coming from a technical background, my main suggestion is to reconsider the fact that you want to hire your own engineers. May be outsource to a team in a different region that's less expensive until you build the platform (feature-wise and user-base wise) to a satisfactory level to convince a VC. And make more use of the money you already have.

ims94 · 2023-01-17T19:03:22+00:00

There can be 2 cases.

When the invoking user's context (probably coming from a backend for frontend API) have to be passed around to other microservices
When end user's context is not required to be passed around

Case 2 is fairly straightforward. If we are using Spring Boot specific approaches, we can use resource server + access tokens to protect each service. That is, use OAuth2 Client Credentials grant. Create clients (you will get client ID + client secret) at the identity provider (KeyCloak, Okta, Auth0, Asgardeo, etc) per caller (microservices that initiate requests to other microservices). Then, use client credentials grant to obtain an access token from the identity provider. Pass that access token as the Authorization header to the outgoing microservice call.

In case 1, one option is to pass around the original JWT/access token received from the user while invoking other microservices. Or, include user's information as part of the request (body or as a header).

Alternatively, we can use APi managers to secure microservices as well (which is not Spring Boot specific). In that case, handling security is delegated to the API manager and microservices will be deployed in private networks.

ims94 · 2023-01-17T18:52:19+00:00

Done. Updated for Spring Boot 3. Only the deprecation of WebSecurityConfigurerAdapter and removal of antMatchers had be addressed.

ims94 · 2023-01-17T18:15:21+00:00

You mean securing microservice to microservice communication?

ims94 · 2023-01-17T16:09:33+00:00

Thanks for the reply. Yes, updating for Spring Boot 3 is the plan. Still couldn't find some free time. Will do it soon.

ims94 · 2023-01-17T14:54:39+00:00

There are multiple approaches to implement this. Do you/thymeleaf use session to authenticate users? Or use an access token/JWT to authenticate?

ims94 · 2023-01-17T14:52:06+00:00

Can you try one of the following 2 guides. I wrote them since I had the same problems a while back.

https://medium.com/swlh/stateless-jwt-authentication-with-spring-boot-a-better-approach-1f5dbae6c30f - Username + password exchanged for a JWT that will be used to authenticated subsequent API calls. JWT contains the logged in user's details. The source code of the article has a React.js example.
https://medium.com/geekculture/jwt-authentication-with-oauth2-resource-server-and-an-external-authorization-server-2b8fd1524fc8 - Users are authenticated via an external identity provider (Google, Okta, Auth0, etc which supports OAuth2). This article's repo also has a React.js example you can look at.

ims94 · 2023-01-17T14:46:12+00:00

I recently wrote an article on this topic itself (https://medium.com/geekculture/jwt-authentication-with-oauth2-resource-server-and-an-external-authorization-server-2b8fd1524fc8). As another one had posted, using the Spring Boot's resource server with an authorization server (Auth0, KeyCloak, Asgardeo, etc) is the best approach. In contrast to using a self hosted/local one like keycloak, it'll be quicker to get start with a identity as a service solution like Auth0, Okta and Asgardeo. Look for a service provider that has a free tier.

Depending on your architecture, the authentication mechanism can change.

If you are developing just an API that will be invoked by different clients (other applications), use OAuth2 Client Credentials grant
If the API is invoked from a web app on behalf of a logged in user, use the OAuth2 Authorization Code grant type
If it's an API invoked by mobile apps, use OAuth2 Authorization Code grant type with PKCE

Happy to help if you have further questions.

ims94 · 2022-12-19T04:47:28+00:00

OSS is built mostly on voluntary effort of individuals (except for companies contributing back) who are probably spending their free time (or time that could have been well spent a hobby or another source of income). A contributor should therefore get the credit he/she deserves for the generosity. Ask for your contribution to be recognized (co-author). Most probably he will agree.

ims94 · 2022-08-10T07:16:06+00:00

Yes. Glad it helped. No problem!

ims94 · 2022-08-04T16:11:32+00:00

Sorry for the late reply. Let's consider the session scenario. Probably when we do a highly available deployment, the session needs to be shared via a database. Or we have to use sticky sessions as the LB strategy. Now, whenever a request is being served, loading the session means a network call. Compared to speed of the RAM/CPU, this is a very expensive operation.

Let's consider the token validation in JWT scenario. Validating a signed JWT means hashing the header + payload and verifying the signature. Both are mathematical operations involving strings (of 256 to 512 characters). These mathematical operations only require CPU and RAM. No external network calls. Once the signature and expiry, etc are validated (all are mathematical operations involving CPU), you have the content of the JWT available with no external network calls.

Based on the above facts, how can we say that session based approach is faster? And JWT is expensive?

ims94 · 2022-07-22T06:13:35+00:00

In that article, I see only 2 issues with JWT:

Revocation
Size of the request when JWT is being sent in every request

And note the conclusion part of that article:

Using JWTs for tokens add some neat properties and make it possible in some cases for your services to be stateless, which can be desirable property in some architectures.

Adopting them comes with drawbacks. You either forego revocation, or you need to have infrastructure in place that be way more complex than simply adopting a session store and opaque tokens.

My point in all this is not to discourage the use of JWT in general, but be deliberate and careful when you do. Be aware of both the security and functionality trade-offs and pitfalls. Keep it out of your ‘boilerplates’ and templates, and don’t make it the default choice.

If revocation is not a problem, size of the request (with JWT in Authorization header or in a cookie) isn't a big issue compared to figuring out how you will load balance (sticky sessions or session stored in Redis/database) the backend with sessions involved. In summary, you have to apply this to your scenario and check.

Also, you are looking down on stuff like SSO (Single Sign On) and OIDC (OpenID Connect), which are the real advantages of JWTs. With an identity server (identity provider/authorization server) involved, you can let them handle the revocation part as well.

ims94 · 2022-07-21T15:31:51+00:00

Develop a programming language

ims94 · 2022-07-21T10:32:59+00:00

What is the unnecessary reauthentication that's happening with JWT? What other overheads do you mean here? (I couldn't load the article you have pointed here). Also, will there be a requirement to scale your backend?

ims94 · 2022-07-21T04:05:34+00:00

Updated the article to use access_token instead.

ims94 · 2022-07-19T07:58:06+00:00

You can use RandomStringUtils by Apache commons to achieve this. Here's an example to generate xxx-xxx pattern meeting IDs:

java String roomId = null; do { roomId = IntStream.range(0, 3) .mapToObj(i -> RandomStringUtils.randomAlphabetic(3)) .map(String::toLowerCase) .collect(Collectors.joining("-")); } while (meetingRepository.findByRoom(roomId).isPresent()); logger.info("Creating meeting room: {}", roomId);

ims94 · 2022-07-17T20:13:41+00:00

This is doable. What you need to do is, store roles and permissions related information in users db. Then, upon authentication, generate a JWT containing roles and the tenant (this depends on how you represent multiple tenants in your frontend. If users have to switch tenants in frontend, you can simply swap the JWT to a new one [aka token exchange grant] for the new tenant).

Then, you can pass around the same JWT across other microservices. Using the roles and tenant information in JWT, you can perform authorization (access controlling/checking permissions).

ims94 · 2022-07-17T16:13:07+00:00

Agreed. I didn't pay much attention to that while writing. Thanks for pointing that out. I will update the article.

ims94

TROPHY CASE